• Author / Uploaded
• Edison Arrunategui

Citation preview

Seguridad en comunicaciones de servicios Web

Santiago Hurtado

Universidad de los Andes Facultad de Ingeniería Departamento de Ingeniería de Sistemas Bogotá D.C. ,2008

Seguridad en comunicaciones de servicios Web

Santiago Hurtado

Proyecto de Grado Director Nicolás López

Universidad de los Andes Facultad de Ingeniería Departamento de Ingeniería de Sistemas Bogotá D.C. ,2008

Nota de aceptación: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________

__________________________ Director de Proyecto __________________________ Jurado __________________________ Jurado

Tabla de contenidos INTRODUCCIÓN ........................................................................................................................................... 6 MOTIVACIÓN ............................................................................................................................................... 7 OBJETIVOS ................................................................................................................................................... 8 OBJETIVO GENERAL ............................................................................................................................................. 8 OBJETIVOS ESPECÍFICOS ....................................................................................................................................... 8 CONTEXTO ................................................................................................................................................... 9 SEGURIDAD ........................................................................................................................................................ 9 Identificación y autenticación .................................................................................................................... 9 Autorización ............................................................................................................................................... 9 No repudiación........................................................................................................................................... 9 Privacidad y confidencialidad .................................................................................................................... 9 Integridad .................................................................................................................................................. 9 Accountability ............................................................................................................................................ 9 SERVICIOS WEB (3) ........................................................................................................................................... 10 Propiedades ............................................................................................................................................. 10 Estándares de seguridad.......................................................................................................................... 11 JAX-WS ..................................................................................................................................................... 12 SISTEMAS DISTRIBUIDOS ..................................................................................................................................... 13 Modelo de referencia de procesamiento abierto y distribuido ................................................................ 14 ESCENARIOS DE CALIDAD........................................................................................................................... 15 AUTENTICACIÓN DE SERVICIOS ............................................................................................................................. 15 Descripción............................................................................................................................................... 15 Escenario.................................................................................................................................................. 15 NO REPUDIACIÓN .............................................................................................................................................. 16 Descripción............................................................................................................................................... 16 Escenario.................................................................................................................................................. 17 ACCOUNTABILITY .............................................................................................................................................. 19 Descripción............................................................................................................................................... 19 Escenario.................................................................................................................................................. 19 TRANSPARENCIA ............................................................................................................................................... 21 Descripción............................................................................................................................................... 21 Escenario.................................................................................................................................................. 21 DISEÑO ...................................................................................................................................................... 25 ARQUITECTURA ................................................................................................................................................ 25 Vista de despliegue .................................................................................................................................. 25 Vista funcional ......................................................................................................................................... 26 DISEÑO DETALLADO .................................................................................................................................. 29

DIAGRAMAS DE FLUJO ........................................................................................................................................ 29 No repudiación......................................................................................................................................... 29 Autenticación de Servicios ....................................................................................................................... 29 Accountability .......................................................................................................................................... 30 DIAGRAMA DE CLASES ....................................................................................................................................... 30 Conector................................................................................................................................................... 30 Certificados .............................................................................................................................................. 31 Accountability .......................................................................................................................................... 32 PROTOTIPO ................................................................................................................................................ 33 HERRAMIENTAS ................................................................................................................................................ 33 CREAR SERVICIO WEB ....................................................................................................................................... 33 Anotaciones ............................................................................................................................................. 33 WSDL........................................................................................................................................................ 34 Despliegue ............................................................................................................................................... 34 CREAR CLIENTE SERVICIO WEB ........................................................................................................................... 34 Generación de Artefactos ........................................................................................................................ 35 EXTENSIÓN DE HANDLERS DE JAX-WS .................................................................................................................. 35 USO DE LOS HANDLERS DEL MODULO DE SEGURIDAD ................................................................................................ 36 TRABAJO FUTURO ...................................................................................................................................... 37 CIFRADO DE MENSAJES SOAP ............................................................................................................................. 37 UTILIZAR CIFRADO PARA CONEXIONES DE SERVICIOS WEB ......................................................................................... 37 INTEGRACIÓN DE BO A OBJETOS XML ................................................................................................................... 37 CREAR ANOTACIONES......................................................................................................................................... 37 MEJORAR EL PARSEADO DE MENSAJES SOAP.......................................................................................................... 37 CONCLUSIONES .......................................................................................................................................... 38 BIBLIOGRAFÍA ............................................................................................................................................ 39 LISTA DE FIGURAS ...................................................................................................................................... 41 GLOSARIO .................................................................................................................................................. 42 SERVICIO WEB .......................................................................................................................................... 42 XML .......................................................................................................................................................... 42 SOAP ........................................................................................................................................................ 42 JAXB ......................................................................................................................................................... 42 SAAJ ......................................................................................................................................................... 42 W3C ......................................................................................................................................................... 42 WSDL........................................................................................................................................................ 42

Introducción En este documento se presentan los estándares de seguridad definidos por la industria para el manejo de servicios Web XML, para luego presentar las tecnologías necesarias para implementarlos en la plataforma JEE5. Se plantea una arquitectura objetivo para proveer servicios, que permitan que nuevos proyectos utilicen estos servicios para asegurar sus comunicaciones mediante servicios web. Se muestran detalles de cómo crear los servicios web y sus clientes para poder hacer uso de los servicios que provee el modulo de seguridad. Por último se realizó un prototipo de la arquitectura objetivo, utilizando como ejemplo el conector del modulo de seguridad, el cual se modifico para que utilizara servicios web y así proveer sus funcionalidades con transparencia de acceso.

Motivación La globalización de las empresas ha generado la necesidad de tener sistemas distribuidos. Los servicios web son una solución posible para satisfacer esta demanda. Los servicios web cumplen el rol de conectores entre diferentes sistemas de información; esta característica trae muchos beneficios, pero a su vez compromete la seguridad. El interés en los servicios web esta en las características que ofrecen. Son portables, fiables y soportan conexiones, tanto sincrónicas como asincrónicas. Se van a estudiar como componentes de comunicaciones transparentes, cuyo fin es lograr solucionar el problema existente en las aplicaciones de Qualdev; las cuales dependen en gran parte de que los puertos necesarios para la comunicación, estén abiertos en el firewall del servidor. Es necesario que estos cumplan estándares de seguridad, dado que las comunicaciones pueden estar comprometidas en el envió de mensajes con información sensitiva. Es importante subrayar que la seguridad, no es únicamente el cifrado de los canales de comunicación, también es necesario incluir otros atributos que aseguren la calidad de los servicios ofrecidos; logrando apoyar y asegurar la información.

Objetivos Objetivo General Construir un prototipo para proveer servicios web XML como componentes, el cual cumpla los estándares de: seguridad, autenticación, no repudiación y auditoria, proporcionando transparencia de acceso.

Objetivos Específicos • •

• •

•

Identificar los estándares en servicios web XML de mayor importancia para satisfacer la seguridad. Identificar de qué forma los servicios web XML proveen transparencia, como uno de los cuatro elementos fundamentales del modelo RM-ODP1 ; de manera que puedan ser componentes de comunicación segura en sistemas distribuidos. Definir escenarios de calidad de las propiedades de seguridad, para comprobar cómo los servicios web los satisfacen. Realizar el análisis, diseño y definición de una arquitectura objetivo para ser incluida con el modulo de seguridad y lograr que las aplicaciones puedan ofrecer sus servicios de una forma fácil y segura. Construir un prototipo para la conexión entre la herramienta PlanningTool2 y el modulo de seguridad, con servicios web con la tecnología JAX-WS3 cumpliendo los estándares de seguridad definidos.

1

Modelo de referencia de procesamiento abierto y distribuido RM-ODP proporciona un marco de coordinación para la normalización del desarrollo de aplicaciones abiertas y distribuidas.

2

PlanningTool es una herramienta que pretende extender la funcionalidad de dotProject que permita un mejor manejo de la planeación y seguimiento de proyectos de software.

3

Es una tecnología diseñada para simplificar la construcción de servicios web y clientes para servicios web.

Contexto Seguridad La seguridad de la información debe cumplir con diferentes atributos, logrando que sea de uso restringido a las personas autorizadas, manteniendo la integridad y la persistencia. (1) Los principales son: Identificación y autenticación Verificación de la identidad del usuario, proceso o servicio, como prerrequisito para confiar el acceso a recursos en un sistema de información. Autorización Otorgar permisos para utilizar un recurso suministrado directa o indirectamente por una aplicación o el propietario de un sistema. No repudiación Asegurar que el emisor reciba prueba de envió y el receptor prueba de identidad del emisor, para que ninguno pueda negar tener la información y que esta sea correcta. Privacidad y confidencialidad Garantizar los procesos, políticas y controles utilizados para proteger la información, de accesos sin autorización. Integridad Asegurar que la información no ha sido alterada de una manera no autorizada, la cual pueda comprometer completitud, disponibilidad y precisión. Accountability4 Observar eventos y archivarlos. Esta información debe estar disponible para ser verificada. Lo cual permita reproducir acciones en un sistema. (2)

4

Responsabilidad

Servicios Web (3) Los servicios web son componentes que hacen posible interactuar sistemas distribuidos y procesos de TI heterogéneos, los cuales pueden realizar desde las tareas más sencillas hasta las más complejas. Estos son aplicaciones modulares auto contenidas, las cuales pueden ser descritas, ubicadas e invocadas utilizando el mismo estándar web de transporte; que necesitan un lenguaje común para intercambiar datos, como lo es XML. Al igual que los sistemas orientados por objetos, los conceptos fundamentales de los servicios web son la encapsulación, el envió de mensajes y la consulta y descripción de servicios. El rol fundamental de los servicios web, es ser proveedores, consumidores e intermediarios de servicios. Lo cual introduce aspectos como la seguridad, flujo de mensajes, transacciones, calidad del servicio y acuerdos de servicio. La arquitectura de servicios web provee múltiples beneficios, los cuales incluyen entre otros: •

Promover la interoperabilidad, minimizando los requerimientos para compartir el entendimiento entre los servicios.

•

Reducir la complejidad de la encapsulación.

•

Dar la posibilidad de conectarse a aplicaciones legado.

Propiedades Las propiedades principales de los servicios web son las siguientes (4)y (5): Basados en XML Dado que los servicios web utilizan XML en la capa de representación, permite que los sistemas heterogéneos inter operen eficientemente. Bajo acoplamiento Las interfaces de los servicios web, pueden ser modificadas sin comprometer la habilidad del cliente, para interactuar con el servicio. Granularidad de servicios La granularidad de operaciones, es una característica importante de diseño; se recomienda utilizar una baja granularidad para consumir servicios externamente, dado que garantizan que el consumidor del recurso va a utilizar el servicio consistentemente. Habilidad para comunicación sincrónica y asincrónica

Los servicios web pueden proveer comunicación; sincrónica cuando sea necesario, pero la capacidad de comunicación asincrónica, es la que los hace importantes, siendo la clave para sistemas de bajo acoplamiento. Soporta Llamadas de procedimientos remotos Los servicios web permiten a los clientes llamar procedimientos, funciones y métodos en objetos remotos, utilizando un protocolo basado en XML. Soporta intercambio de documentos La ventaja clave de XML, es la forma genérica de representar documentos complejos. Los servicios web, soportan el intercambio de documentos en forma transparente, para facilitar la integración de negocios. Estándares de seguridad En este proyecto nos vamos a enfocar en los estándares de seguridad en los mensajes SOAP5, que nos ayudarán a solucionar los problemas de seguridad en autenticación, no repudiación y auditoria en los servicios web. Los estándares definidos, son independientes de las tecnologías que apoyan los servicios web y la forma en que se utilicen. Dado que los servicios web XML basan el intercambio de mensajes en SOAP, pueden usar diferentes aplicaciones de transporte o protocolos, que pueden o no tener un modelo de seguridad. También los servicios web permiten que existan intermediarios, los cuales pueden modificar los mensajes, por lo que el modelo de seguridad debe incluir un manejo de estos intermediarios. (6) WS-Security Estándar definido por OASIS6 el cual provee las funciones básicas, definiendo mecanismos para asegurar: autenticidad, integridad y confidencialidad de los mensajes. La especificación propone un conjunto de estándares, para la extensión de SOAP 1.1 y SOAP 1.2 que pueden ser utilizados cuando se construyen servicios web seguros. Adicionalmente, describe como codificar tokens seguros y agregarlos a los mensajes SOAP. Estos tokens pueden ser ampliados y utilizados con otros protocolos de servicios web para orientarlos en una variedad de requerimientos de seguridad. (2) WS-Security Policy 5

Simple Object Access Protocol

6

Organization for the Advancement of Structured Information Standards (18)

Estándar definido por OASIS, que define un framework donde los servicios web, pueden expresar las limitaciones y requerimientos, los cuales pueden ser expresados como políticas que describen como los mensajes deben ser asegurados, incluyendo el nivel de seguridad de transporte. La intención es proveer suficiente información, a los participantes para tener un intercambio seguro de mensajes. Este framework provee la flexibilidad necesaria para definir estas políticas, con diferentes herramientas de seguridad. (3) WS-SecureConversation Aunque la autenticación es conveniente para mensajes simples o en una sola dirección.; cuando es necesario intercambiar múltiples mensajes, es deseable establecer un contexto de seguridad. Es un estándar definido por OASIS que define, describe y especifica como los contextos son establecidos. Por lo que determina extensiones para permitir, establecer y compartir contextos seguros, mejorando la seguridad y el desempeño de los intercambios de mensajes posteriores. (3) SAML7 Estándar definido por OASIS que extiende el estándar WS-Security, el cual provee medios donde la autenticación y las afirmaciones de autorización pueden ser intercambiadas entre los servicios; logrando comunicar tokens de autenticación de usuarios y permitir que las entidades de negocio realicen afirmaciones con respecto a la identidad, atributos y derechos de los usuarios con respecto a otras entidades. (4) JAX-WS8 Es una tecnología incluida en la plataforma JEE59 diseñada para simplificar la construcción de servicios web y sus clientes los cuales se comunican intercambiando mensajes SOAP. La importancia de JAX-WS se basa en que no es restrictiva, dado que un cliente puede acceder a un servicio web que no esté corriendo en Java y lo mismo a la inversa. Esta flexibilidad es dada ya que utiliza tecnologías definidas por W3C (11)

7

Security Assertion Markup Language

8

Java API for XML Web Services

9

Java Platform, Enterprise Edition 5

Incluye la arquitectura, para realizar la vinculación de XML JAXB10 y el API SAAJ11. Además ayuda a acelerar la creación de servicios web, permitiendo el uso de anotaciones en clases POJO para convertirlos en servicios web. Por último especifica un mapeo detallado de un servicio definido en WSDL12 a clases java que implementan el servicio. Cualquier tipo de datos complejo definido en el WSDL es asignada a las clases Java siguiendo la definición de la especificación JAXB (11). Para el uso de JAX-WS se puede utilizar uno de los siguientes dos enfoques: Contrato primero Se inicia con un contrato WSDL y se generan las clases java para implementar el servicio. Este enfoque requiere un buen entendimiento de WSDL y esquemas XML para definir el formato de los mensajes. Código Primero Inicia con las clases en java y usa anotaciones para generar WSDL y la interfaz Java. Se recomienda iniciar con este enfoque, si no se tiene experiencia al desarrollar servicios web. Además es bastante útil cuando la implementación de Java ya existe.

Sistemas distribuidos El crecimiento del desarrollo de servicios web y los estándares en busca de soporte de la automatización e integración de negocios, ha conducido a grandes avances tecnológicos en el área de integración de software, especialmente en SOA 13 . El propósito de esta arquitectura es solucionar los requerimientos de bajo acoplamiento, basados en estándares y computación distribuida independiente del protocolo. (12) SOA es un framework que combina funciones y procesos individuales de negocios llamados servicios, para implementar aplicaciones y procesos de negocios sofisticados. SOA es un enfoque para TI14 , que considera los procesos como componentes reutilizables o servicios que son independientes de las aplicaciones y las plataformas computacionales en las cuales ellos corren. (13) 10

Java Architecture for XML Binding

11

SOAP with Attachments API for Java

12

Web Services Description Language

13

Service Oriented Arquitecture

14

Tecnologías de información

Modelo de referencia de procesamiento abierto y distribuido El objetivo de la estandarización de ODP15 es el desarrollo de estándares, que permiten los beneficios de distribuir servicios de procesamiento de información, en un ambiente heterogéneo de recursos de TI y múltiples dominios en las organizaciones. Estos estándares dirigen las limitaciones en un sistema de especificación y suministro de la infraestructura, que acomoda las dificultades inherentes en el diseño y programación de sistemas distribuidos. (14) Los elementos fundamentales de este estándar son: • • • •

Enfoque en la modelación de objetos, para especificación de sistemas. Especificación de un sistema, en términos de especificaciones de puntos de vista, separados pero inter relacionados. La definición de una infraestructura, que provea transparencias distribuidas para aplicaciones de sistemas. Un framework para la evaluación de conformidad de los sistemas.

Transparencia de distribución La transparencia en distribución permite que las complejidades asociadas, con sistemas distribuidos, sean ocultadas en las aplicaciones donde son irrelevantes para su propósito. Transparencia en acceso Disfraza, las diferencias de representación e invocación de mecanismos para servicios entre sistemas. Esta transparencia, soluciona muchos de los problemas de colaboración entre sistemas heterogéneos y generalmente es suministrada por defecto. Transparencia en ubicación Disfraza la necesidad de una aplicación, para tener información acerca de la ubicación e invocar el servicio. Esta transparencia provee un nombramiento independiente a la ubicación física.

15

Open distributed process

Escenarios de Calidad Con el fin de proveer servicios externos para el modulo de seguridad, se creó el conector de Java en busca de estandarizar la utilización remota de los servicios que suministra. Para que un conector sea adecuado debe tener formas de conectarse al servidor, sin importar su ubicación. Se seleccionaron los servicios web para este trabajo, por su bajo acoplamiento y por su portabilidad e interoperabilidad con otros lenguajes. Es importante señalar, que se escogió la tecnología JAX-WS por su fácil implementación sobre servicios Java ya diseñados, dado que se pueden utilizar anotaciones en las interfaces y no debe ser modificado el código ya existente. Los servicios web XML tienen varios niveles de comunicación, en los que se pueden aplicar modelos y estándares de seguridad. Por un lado a nivel de la capa de transporte, se puede seleccionar el cifrado del canal. Por otro lado, en el nivel de la capa de aplicaciones se pueden utilizar estándares como WS-Security para permitir seguridad a nivel del intercambio de mensajes, lo cual permite que los atributos de calidad sean cumplidos.

Autenticación de servicios Descripción Únicamente los autorizados pueden consumir el servicio. Escenario Un servicio intenta acceder a los servicios que suministra el proveedor de servicios: • • • • • •

Fuente: Servicio con certificado no valido Estimulo: Inicio de transacción Artefacto: proveedor de servicio Ambiente: Bajo operaciones normales Respuesta: Acepta o no la solicitud para dar servicio Medida: No da el servicio en el 100% de los casos

Estructuras Para cumplir con este escenario, el modulo de seguridad provee un servicio de generación de certificados digitales, que cumplen con los estándares de WS-Security y WS-Trust, adicional a esto provee un servicio de verificación de certificados, los cuales fueron proporcionados por el modulo de seguridad.

FIGURA 1, ESTRUCTURA AUTENTICACIÓN DE SERVICIOS

Protocolos Se muestra el proceso en la figura 2. Cuando el consumidor desea utilizar servicios, envía sus mensajes con un certificado digital al proveedor, el cual verifica el estado del certificado y establece un contexto de seguridad para los siguientes mensajes. Si el certificado no cumple con las políticas, se niega la solicitud del servicio.

FIGURA 2, PROTOCOLO AUTENTICACIÓN DE SERVICIOS

No repudiación Descripción La no repudiación es uno de los atributos, en los que cumplir con el 100% de la eficacia compromete en un alto grado el rendimiento de las aplicaciones.

Se puede implementar sencillamente con una prueba de envió y recepción desde cada servicio, pero su eficacia es altamente cuestionable, dado que puede existir un intermediario que genere ambos y modifique la información. La propuesta que se menciona en este documento, es bastante eficaz pero tiene un alto impacto en el rendimiento del intercambio de mensajes y existen formas de pasar por alto este atributo logrando comprometer la seguridad de las aplicaciones. Una forma con la cual se logra complementar la no repudiación, es mediante el uso de seguridad a nivel de la capa de transporte. Escenario Un servicio intercepta la información enviada por el proveedor y la modifica para luego ser enviada al consumidor. Dado que el modulo de seguridad recibe un certificado modificado o el resumen de información es incorrecto, ambos servicios descartan haber enviado y recibido el mensaje. • • • • • •

Fuente: Usuario malintencionado intercepta y modifica información. Estimulo: Transacción interceptada Artefacto: Modulo de seguridad, Servicio Proveedor y Servicio consumidor Ambiente: Una vez se pide la información al proveedor, se suplanta el servicio y se provee información incorrecta. Respuesta: Acepta o no el mensaje enviado por el usuario mal intencionado Medida: No se acepta el mensaje en el 100% de los casos

Estructuras En orden de que se cumpla este escenario, el modulo debe proveer el servicio de expedición y verificación de certificados, al igual que el escenario de calidad de autenticación. Adicional a esto, debe proveer un servicio para recibir y enviar las pruebas de envió y recepción de mensajes. Este servicio es la base del aseguramiento de la no repudiacion, donde el modelo provee prueba de origen obligatoria y prueba de recepción obligatoria, con el uso del modulo de seguridad como intermediario. Las pruebas de envió y recepción no son intercambiadas, hasta tanto el proveedor y el consumidor del servicio no hayan enviado su prueba de envió y recepción. Para esto se deben utilizar los estándares WSReliability, donde se especifica a quien deben ser enviadas estas pruebas, las cuales son verificadas por el modulo de seguridad. El cual incluye clientes intermedios encargados de enviar y verificarlas, para que sea transparente para el desarrollador. Esta transparencia es restringida a que el desarrollador solicite el servicio por medio de anotaciones en el código.

FIGURA 3, ESTRUCTURA GENERAL NO REPUDIACION

Para asegurar que en los servicios de proveedor y consumidor esto suceda, se deben establecer políticas para el intercambio de mensajes. Estas políticas pueden ser definidas en el WSDL de los servicios y/o utilizando los clientes intermedios que garantizan que estas políticas sean cumplidas. Debido a que se utilizan los estándares de la industria, se podría recurrir únicamente al cliente intermedio en el servicio proveedor o consumidor. Cuando se utilizan clientes y servicios web en JAX-WS se recomienda utilizar ambos para que el desarrollador, solo tenga que preocuparse en que su servicio funcione correctamente, una vez agregado el cliente intermedio este hará cumplir las políticas.

FIGURA 4, ESTRUCTURA NO REPUDIACIÓN

Protocolos El consumidor solicita información; el proveedor se la suministra y envía una prueba al modulo de seguridad. El usuario o servicio mal intencionado intercepta la información y la modifica, luego la reenvía al consumidor; una vez el consumidor recibe la información, envía una prueba de recepción del mensaje. El modulo de seguridad verifica los

certificados y las pruebas de envió/recepción, dado que no corresponden, envía un mensaje de error a ambos servicios (figura 5).

FIGURA 5, PROTOCOLO NO REPUDIACIÓN

Accountability Descripción Se puede reconstruir la información necesaria, para tener un servicio o un usuario responsable, de las acciones realizadas dentro del sistema. En la seguridad uno de los atributos más importantes es el de accountability, el cual incluye el uso de registros y la auditoria de estos para lograr cumplir el atributo. La importancia de este atributo radica, en que este provee una forma muy efectiva de encontrar vulnerabilidades en los sistemas, servicios y herramientas. La complejidad consiste en que para que la información de los registros sea útil, se debe lograr y analizar esta información. Si se tiene mucha información no será posible entenderla o tomará demasiado tiempo. Si es muy poca o inexacta la información no servirá de nada, más que para ocupar espacio en el sistema. Escenario La perdida de información, hace evidente una vulnerabilidad del sistema; para lograr corregirla se debe encontrar la fuente de esta modificación. Para encontrarla es importante tener información de quien realizo la modificación y cuando, logrando que con esta se reduzca en lo posible el origen de la inconsistencia. • • • • • •

Fuente: Servicio o persona que encuentra información inconsistente o modificada. Estimulo: Solicitud de revisión de información inconsistente o modificada Artefacto: Modulo de seguridad Ambiente: Bajo operaciones normales Respuesta: Se encuentra la fuente que modifico la información afectada en el servicio. Medida: Se reducen al 5% los usuarios que pudieron modificar la información

Estructuras

Esta estructura básica (figura 6), es la misma que se utiliza en la no repudiación para la recepción de las pruebas de envió y recepción de mensajes; lo importante es que ésta sea extensible, para lograr incluir otros mensajes o informaciones, las cuales sean enviadas al modulo de seguridad.

FIGURA 6, ESTRUCTURA GENERAL ACCOUNTABILITY

Se debe incluir un servicio, que sea capaz de interpretar la información almacenada, para su uso posterior. Para el análisis de la información éste debe ser extensible a nuevas funcionalidades según sea necesario.

FIGURA 7, ESTRUCTURA ACCOUNTABILITY

Protocolos Los protocolos en la auditoria son dos: uno para recepción de información(figura 8) y otro para el análisis y envió de información solicitada. Es necesario incluir el modelo de seguridad de autenticación, para que el uso de esta información sea apropiado. Cada servicio en sus políticas debe definir cuando y que mensajes, al ser enviados deben despachar un resumen al modulo de seguridad, para mantener un registro de estos.

FIGURA 8, PROTOCOLO ACCOUNTABILITY

Transparencia Descripción Para proveer los servicios del conector, es un factor muy importante lograr la transparencia en el acceso, ya que una herramienta que utilice el conector, puede estar en la red Interna del modulo de seguridad, como también puede ser utilizada externamente. Para esto debe proveer al conector de la posibilidad de conectarse de diferentes maneras, al modulo de seguridad. Escenario Un usuario que se encuentra en la red externa al servidor, trata de utilizar los servicios del conector, existe un firewall que bloquea los puertos para esta comunicación. En este escenario el modulo de seguridad intenta proveer los servicios por otro protocolo. Este escenario se ve complementado por los escenarios anteriores, para cumplir la transparencia de acceso sin comprometer la seguridad. Esta transparencia es la que va a cumplir el conector del modulo de seguridad, dado que por la estructura que se diseño, puede proveer diferentes protocolos de comunicación según sea oportuno. En nuestro caso se agregaron conexiones a servicios web para que el modulo de seguridad pueda ser utilizado desde cualquier ubicación. Para esto el desarrollador que utiliza el conector puede configurarlo por medio de servicios web o RMI. Lo ideal es que se realice de una forma automática como lo explicamos en la figura 10. • • • • • •

Fuente: Herramienta que quiere utilizar el servicio Estimulo: Solicitud de servicio Ambiente: El servicio tiene bloqueados los puertos normales Artefacto: Modulo de seguridad Respuesta: Se cumple la solicitud Medida: Sin importar la ubicación del proveedor del servicio y del consumidor se provee el servicio

Estructuras Las estructuras necesarias para este escenario, son los servicios web ya que estos al ser uno de los fundamentos de los sistemas distribuidos, deben proveer transparencia en ubicación según el modelo RM-ODP. Esto lo logran utilizando el protocolo de transporte web conocido como HTTP. Para nuestro modulo de seguridad se provee un conector el cual se comunica por RMI16 a los bean de sesión, del modulo de seguridad. Pero para lograr acceder de forma externa este no logra comunicarse por causa del firewall del servidor principal. La solución propuesta, es que el conector tenga un servicio de comunicación secundario al modulo de seguridad, por medio de los servicios web, donde el rendimiento se puede ver afectado pero la disponibilidad del servicio aumenta.

FIGURA 9, ESTRUCTURA TRANSPARENCIA DE ACCESO

Protocolos El protocolo puede ser seleccionado de dos opciones: 1. Automático Beneficios: El usuario no necesita conocer los aspectos técnicos, sobre el servicio que necesita. Se conecta en orden de obtener la mejor forma de conexión. 16

Remote Method Invocation

Desventajas: La conexión del servicio puede demorarse, mientras prueba las diferentes formas de realizar esta conexión. Descripción: El usuario solicita el servicio. El conector, selecciona la forma predeterminada para establecer la conexión; si no lo logra, continua con la siguiente. Cuando se acaban las formas de conectarse sin lograrlo niega el servicio. Si lo logra continua su funcionamiento normal.

FIGURA 10, PROTOCOLO OPCION 1 TRANSPARENCIA DE ACCESO

2. Configurable Beneficios: Establecer la conexión con el servicio es mucho más veloz Desventajas: El usuario debe entender, como se configura y las ventajas y desventajas de la forma de conexión que va a utilizar. Descripción: El usuario configura la manera como se va a conectar al servicio; solicita conexión si funciona, continua normalmente, si no, muestra el error en la herramienta.

FIGURA 11, PROTOCOLO OPCION 2 TRANSPARENCIA

Diseño Arquitectura Para solucionar estos escenarios de calidad, se propone una arquitectura de dos nuevos componentes, que se van a encontrar en el mismo servidor de aplicaciones. En estos escenarios de calidad podemos observar que se comparten servicios, en el área de certificados y recepción y envió de pruebas. Los certificados son necesarios para autorizar el uso de servicios y para el manejo de no repudiación. También para la no repudiación y la auditoria se puede observar que comparten la estructura de recepción y envió de pruebas de mensajes. Para que todos estos servicios, puedan proveer transparencia de acceso, se deben proveer mediante servicios web. Vista de despliegue Descripción La vista de despliegue muestra, cómo deben ser desplegados los diferentes módulos para utilizar la aplicación. Vista

FIGURA 12, VISTA DE DESPLIEGUE

En esta vista podemos observar dos nodos principales: Nodo Servidor Cada nodo está conformado, por dos componentes principales: el de persistencia y el de sesión. En el servidor de aplicaciones podemos observar tres módulos: •

El modulo de seguridad Provee los servicios de autenticación de usuarios.

•

El modulo de certificados Expide y verifica la validez de estos certificados. Además utiliza los servicios del modulo de autenticación de usuarios para verificar la validez de los usuarios, herramientas y roles.

•

El modulo de accountability Este es el modulo que provee los servicios de recepción y envió de información, que debe ser auditada. Para lo que también utiliza el modulo de seguridad, verificando la validez de usuarios, herramientas y roles.

Nodo Cliente En este nodo se encuentra el conector del modulo de seguridad y todos los servicios que provee el servidor. También se encuentran los handlers que proveen los modulos de certificados, seguridad y accountability, Los cuales ayudan a proveer los servicios de seguridad necesarios en el intercambio de mensajes. Vista funcional Certificados

FIGURA 13, VISTA FUNCIONAL CERTIFICADOS

Descripción Para cumplir con los estándares, de seguridad de autenticación y no repudiación se van a proveer dos servicios principales. La expedición de certificados y la verificación de estos, los cuales utilizan los servicios, que requiere asegurar la comunicación. Componentes funcionales • • •

certificateExpedition: Servicio que expide certificados a las herramientas, las cuales están autorizadas por el modulo de seguridad. certificateVerification: Servicio que verifica los certificados expedidos por este modulo y que corresponden a la herramienta que está solicitando la verificación. certificateMatch: Servicio que compara dos certificados.

Accountability

FIGURA 14, VISTA FUNCIONAL ACCOUNTABILITY

Descripción Para lograr cumplir con la no repudiación y accountability se proveen los servicios de este modulo. Componentes funcionales

• • •

storeLogInfo: Servicio que almacena la información. storeSendProof: Servicio que almacena la prueba de envió storeReceiptProof: Servicio que almacena la prueba de recepción

Vista para no repudiación

FIGURA 15, VISTA FUNCIONAL DE NO REPUDIACIÓN

Diseño detallado Diagramas de flujo No repudiación

FIGURA 16, DIAGRAMA DE FLUJO DE NO REPUDIACIÓN

Autenticación de Servicios

FIGURA 17, DIAGRAMA DE FLUJO DE AUTENTICACIÓN DE SERVICIOS

Accountability

FIGURA 18, DIGRAMA DE FLUJO ACCOUNTABILITY

Diagrama de Clases Conector El conector para clientes Java se modifico, de manera que se pueda extender fácilmente a nuevos tipos de conexiones, para que el usuario final no necesite conocer como se implementan las conexiones. Inicialmente se debe seleccionar el tipo de conexión, por medio de la configuración de este.

FIGURA 19, DIAGRAMA DE CLASES DEL CONECTOR

Certificados El servidor de certificados tiene la complejidad en la capa de sesión, donde debe crear y almacenar los certificados para su posterior uso, adicionalmente al expedir los certificados, debe verificar con el componente de autenticación que la herramienta que está asociada exista. Por otro lado se pude crear un paquete jar con los handlers, los cuales deben tener la capacidad de conectarse transparentemente al modulo de seguridad, para utilizar sus servicios. Esta transparencia debe ser de acceso y en lo posible de ubicación. Es deseable implementar un handler que provea el servicio de cifrado de mensajes, para aumentar la seguridad que provee este modulo. El cifrado debería basarse en el uso de estos certificados.

FIGURA 20, DIAGRAMA DE CLASES DE CERTIFICADOS

Accountability El componente de accountability está provisto en la capa de sesión de dos servicios principales: uno para almacenar log’s y otro para la no repudiación; este servicio es el encargado de verificar las pruebas de envió y recepción para luego proveerlas al servicio proveedor y consumidor. También se puede crear un jar con los handlers para ser distribuido a los servicios, que requieran proveer la no repudiación. Es importante tener en cuenta que estos servicios pueden y es deseable que se utilicen junto a la autenticación de servicios para complementar el modelo de seguridad.

FIGURA 21, DIAGRAMA DE CLASES DE ACCOUNTABILITY

Prototipo Herramientas Las herramientas utilizadas para este proyecto son las siguientes: • • • •

Glassfish v2 Eclipse 3.4.1 Mysql 5.0 Ant

Para el uso del proyecto, se supone que ya se encuentran instaladas y corriendo todas las herramientas necesarias. Para más información, como instalar y configurarlas se recomienda utilizar el manual del desarrollador del grupo de seguridad. http://qualdev.uniandes.edu.co/wikiDev/doku.php?id=development:projects:security:developerg uideline:developerguideline

Crear Servicio WEB Anotaciones En el desarrollo de servicios web se utilizan las anotaciones de JEE5 para crear los servicios web. Para utilizar estos servicios en la capa de sesión, lo que se debe hacer es incluirlos en el paquete jar que va ha ser desplegado en el servidor de aplicaciones.

FIGURA 22, CODIGO PARA SERVICIO WEB JAX-WS

Las anotaciones básicas para crear un servicio web son: @WebService Esta anotación declara la clase como un servicio web. @WebMethod

Esta anotación es utilizada para indicar, cuales métodos van a ser expuestos por el servicio web y tiene parámetros opcionales. @HandlerChain Anotación que permite utilizar la cadena de handlers, definida en un archivo XML. En la figura 23 se muestra el ejemplo del archivo XML para utilizar el handler de autenticación de servicios.

FIGURA 23, HANDLER CHAIN

WSDL Para extender el archivo básico WSDL, generado al subir la clase al servidor de aplicaciones, se deben utilizar anotaciones o generar el archivo WSDL con la tarea ant y luego modificarlo. Despliegue La construcción del modulo de seguridad se realiza por medio de una tarea ant. Para realizar el despliegue se debe utilizar el administrador del servido de aplicaciones Glassfish

Crear Cliente Servicio WEB Para el desarrollo de los clientes se deben generar los artefactos del cliente con la tarea ant y luego utilizar las clases. En la figura 24 se muestra el codigo para crear el cliente de servicios web.

FIGURA 24, CODIGO PARA CLIENTES DE SERVICIOS WEB JAX-WS

En el paquete “co.edu.uniandes.qualdevsecurity.connector.connections.ws” se encuentra la clase “SecurityWebServiceSessionService” la cual realiza la conexión con el servicio web y luego se pide el puerto de sesión para obtener conexión, con la interfaz del “SecurityWebServiceSession” y así poder utilizar los servicios del servicio web. En las siguientes líneas de la figura 24 podemos observar cómo se agrega un handler a la cadena de handlers, aunque se puede hacer con anotaciones, para el propósito del prototipo se utiliza de esta manera. Generación de Artefactos Las clases mencionadas anteriormente son generadas. En la figura 25 se muestra la tarea “WS Client Artifacts” que es la encargada de hacer esta generación dado un WSDL. Se debe tener en cuenta que los objetos BO son asignados a objetos XML, por lo que en nuestro caso deben ser convertidos de nuevo a los BO originales.

FIGURA 25, TAREA ANT PARA GENERAR ARTEFACTOS DE CLIENTE

Se utiliza wsimport para crear los artefactos, estos artefactos hacen posible el análisis de la información, sin necesidad de realizar esta transformación por medio de parsers.

Extensión de handlers de JAX-WS La base de este prototipo son los handlers de mensajes SOAP, estos handlers son implementaciones de SOAPHandler donde existe un método principal, handleMessage que provee la facilidad de modificar estos mensajes antes de ser enviados al servicio o al recibirlos.

FIGURA 26, EXTENSIÓN DE HANDLERS

Es importante anotar que estos mensajes son estructuras XML, por lo que pueden ser parseados para agregar, cambiar y leer los datos de estos mensajes. La especificación predeterminada para

realizar este parseado, es por medio de SAAJ, pero se puede utilizar cualquier otro método como DOM, JAX o STAX.

Uso de los handlers del modulo de seguridad Estos handlers nos ayudan a modificar los encabezados SOAP, para que cumplan con los estándares WS-Security. En la figura 27 mostramos un mensaje soap después de ser procesado por el handler.

FIGURA 27, MENSAJE SOAP

En la figura 28 mostramos un ejemplo del handler de servidor de autenticación de servicios, donde se verifica el encabezado de seguridad y se obtiene la información necesaria para verificar el certificado.

FIGURA 28, VERIFICACION DE ENCABEZADO

Por último en la figura 29, mostramos un ejemplo del handler del cliente, que anexa el certificado al encabezado del mensaje antes de ser enviado.

FIGURA 29, ANEXAR ENCABEZADO DE SEGURIDAD

Trabajo Futuro Cifrado de mensajes SOAP Por medio de la misma estrategia presentada en este proyecto, se puede implementar el cifrado de los mensajes para garantizar la privacidad y confidencialidad. Aunque en la definición del estándar de seguridad es posible cifrar elemento por elemento, para lograr mantener una transparencia en el uso de los handler, se recomienda cifrar el cuerpo completo del mensaje.

Utilizar cifrado para conexiones de servicios WEB Es importante tener la posibilidad, de cifrar la información en la capa de transporte ya que esto da seguridad adicional en las comunicaciones de los mensajes. También provee una transparencia en el manejo de la seguridad. Esta seguridad puede ser exigida por medio de políticas en el documento WSDL, agregada en cada mensaje por medio del uso de handlers o por el cliente o servicio web.

Integración de BO a objetos XML Dado que al generar el código del cliente se crean objetos JAXP, es necesario convertirlos de nuevo a Business Objects. Sería de gran ayuda estudiar una forma para que no se requiera realizar este procedimiento adicional

Crear anotaciones Para aumentar el nivel de transparencia, es necesario crear y extender las anotaciones para que sea mucho más sencillo utilizar nuestra infraestructura.

Mejorar el parseado de mensajes SOAP El manejo de los mensajes SOAP tiene un inconveniente a la hora de analizar estos mensajes. En el prototipo se realizan muchas suposiciones a la hora de leer, escribir y modificar estos encabezados. Un buen manejo del parseado de estos mensajes incrementa la flexibilidad en esta manipulación. Se recomienda revisar tecnologías como XPath y STAX.

Conclusiones La infraestructura JEE para crear servicios web es muy completa y ayuda a crear servicios y clientes web, por medio de anotaciones en POJO’s y la generación de código mediante sus herramientas. Es tan flexible que también dá la posibilidad de manipular los mensajes SOAP. Gracias a esta infraestructura, se pueden interceptar y modificar estos mensajes, por medio de los handlers de JAX-WS, que son la base de nuestra solución. Gracias a esta flexibilidad, los estándares de seguridad en los mensajes pueden ser implementados en los servicios web. Para poder implementar estos estándares, se deben realizar modificaciones y verificaciones en XML, de los mensajes que van a ser intercambiados. Se debe tener presente, que en las comunicaciones se debe mantener el uso de tipos sencillos, para que extender estas comunicaciones a otras tecnologías no necesite crear lógica del negocio. Los servicios web nos dan la infraestructura suficiente, para solucionar el problema de transparencia y seguridad encontrado en las herramientas Qualdev. Por medio de este proyecto, se aminora el código adicional y la infraestructura necesarios para proveer la seguridad, al implementar nuevos servicios web.

Bibliografía 1. Singhal, Anoop, Theodore, Winograd y Karen, Scarfone. Guide to secure web services. Gaithersburg, MD, Estados Unidos : s.n., Agosto de 2007. Special Publication 800-95. 2. Schumacher, Markus, y otros. Security Patterns. West Sussex : John Wiley & Sons,Ltd, 2006. 3. Gottschalk, Karl. International Business Machines Corp. [En línea] 06 de Septiembre de 2000. [Citado el: 19 de octubre de 2008.] http://www.ibm.com/developerworks/webservices/library/wovr/. 4. Chappell, David y Jewell, Tyler. Java Web Services. Marzo : O'REYLLY, 2002. 5. Colan, Mark. International Business Machine Corp. [En línea] 21 de abril de 2004. [Citado el: 19 de octubre de 2008.] http://www.ibm.com/developerworks/webservices/library/wssoaintro.html?S_TACT=105AGX04&S_CMP=LP. 6. U, Gopalakrishnan y Ravi, Rajesh. Web services security, Part I. IBM corporation. [En línea] 25 de febrero de 2003. [Citado el: 1 de 11 de 2008.] http://www.ibm.com/developerworks/webservices/library/ws-sec1.html. 7. Varios. International Business Machines Corp. [En línea] 01 de marzo de 2004. [Citado el: 20 de octubre de 2008.] http://www.ibm.com/developerworks/webservices/library/specification/wssecure/. 8. Kelvin Lawrence, IBM Chris Kaler, Microsoft. Oasis Standard. [En línea] 1 de Julio de 2007. [Citado el: 20 de octubre de 2008.] http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf. 9. Scott Cantor, Internet2, y otros. Oasis Standards. [En línea] 15 de marzo de 2005. [Citado el: 20 de octubre de 2008.] http://docs.oasis-open.org/security/saml/v2.0/. 10. The Java EE 5 Tutorial. Santa Clara : Sun Microsystems, Inc., 2007. PartNo: 819–3669–10. 11. Balani, Naveen y Hathi, Rajeev. Design and develop JAX-WS 2.0 Web services. International Business Machines Corp. [En línea] 20 de sep de 2007. [Citado el: 19 de sep de 2008.] http://www.ibm.com/developerworks/edu/ws-dw-ws-jax.html. 12. Service oriented architectures: approaches, technologies. Papazoglou, Mike P. y Heuvel, Willem-Jan van den. Tilburg : s.n., 2007. DOI 10.1007/s00778-007-0044-3. 13. Brown, Alan W., y otros. SOA Development Using the IBM Rational Software Development Platform: A Practical Guide. IBM Corporation. [En línea] septiembre de 2005. [Citado el: 20 de septiembre de 2008.]

14. INTERNATIONAL STANDARD. Information technology — Open Distributed Processing — Reference model: Overview. [En línea] 15 de 12 de 1998. [Citado el: 25 de octubre de 2008.] ISO/IEC 10746-1. 15. Harold, Elliotte Rusty y Means, W. Scott. XML in a Nutshell. s.l. : O'REILLY, 2002. ISBN 0-59600292-0. 16. W3C. [En línea] [Citado el: 29 de 11 de 2008.] http://www.w3c.es/. 17. Oasis Standards. [En línea] 1 de Febrero de 2006. [Citado el: 20 de octubre de 2008.] http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-osSOAPMessageSecurity.pdf. 18. Kelvin Lawrence, IBM Chris Kaler, Microsoft. Oasis Standards. [En línea] 19 de marzo de 2007. [Citado el: 20 de octubre de 2008.] http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.html. 19. Coffey, Tom y Saidha, Puneet. NON-REPUDIATION WITH MANDATORY PROOF OF RECEIPT. University of Limerick. Ireland : s.n. 20. OASIS Standard. http://www.oasis-open.org. [En línea] 2008. [Citado el: 10 de Noviembre de 2008.] http://www.oasis-open.org/who/.

Lista de figuras FIGURA 1, Estructura autenticación de servicios ---------------------------------------------------------------- 16 FIGURA 2, Protocolo autenticación de servicios ----------------------------------------------------------------- 16 FIGURA 3, estructura general no repudiacion -------------------------------------------------------------------- 18 FIGURA 4, estructura no repudiación------------------------------------------------------------------------------- 18 FIGURA 5, protocolo no repudiación ------------------------------------------------------------------------------- 19 FIGURA 6, estructura general accountability --------------------------------------------------------------------- 20 FIGURA 7, estructura accountability -------------------------------------------------------------------------------- 20 FIGURA 8, protocolo accountability--------------------------------------------------------------------------------- 21 FIGURA 9, estructura transparencia de acceso ------------------------------------------------------------------ 22 FIGURA 10, protocolo opcion 1 transparencia de acceso ----------------------------------------------------- 23 FIGURA 11, Protocolo opcion 2 transparencia ------------------------------------------------------------------- 24 FIGURA 12, vista de despliegue -------------------------------------------------------------------------------------- 25 FIGURA 13, vista funcional certificados ---------------------------------------------------------------------------- 27 FIGURA 14, vista funcional accountability ------------------------------------------------------------------------- 27 FIGURA 15, vista funcional de no repudiación ------------------------------------------------------------------- 28 FIGURA 16, diagrama de flujo de no repudiación --------------------------------------------------------------- 29 FIGURA 17, diagrama de flujo de autenticación de servicios ------------------------------------------------- 29 FIGURA 18, digrama de flujo accountability ---------------------------------------------------------------------- 30 FIGURA 19, diagrama de clases del conector --------------------------------------------------------------------- 31 FIGURA 20, diagrama de clases de certificados ------------------------------------------------------------------ 31 FIGURA 21, diagrama de clases de accountability --------------------------------------------------------------- 32 FIGURA 22, codigo para servicio web jax-ws --------------------------------------------------------------------- 33 FIGURA 23, Handler Chain--------------------------------------------------------------------------------------------- 34 FIGURA 24, codigo para clientes de servicios web jax-ws ----------------------------------------------------- 34 FIGURA 25, Tarea ant para generar artefactos de cliente ----------------------------------------------------- 35 FIGURA 26, Extensión de Handlers ---------------------------------------------------------------------------------- 35 FIGURA 27, Mensaje SOAP -------------------------------------------------------------------------------------------- 36 FIGURA 28, Verificacion de Encabezado --------------------------------------------------------------------------- 36 FIGURA 29, Anexar encabezado de seguridad ------------------------------------------------------------------- 36

Glosario SERVICIO WEB Un servicio web es una pieza de la lógica del negocio, ubicada en alguna parte en internet, la cual es accesible a través de protocolos de internet como HTTP o SMTP. Estos se diferencian de otras tecnologías dado que el se basa en XML (4) XML Extensible Markup Language, es un estandar aprobado por W3C. Define una sintaxis genérica utilizada para apuntar información con simples etiquetas. Este formato es suficientemente flexible para ser personalizado para diversos dominios. (15) SOAP Simple Object Access Protocol, provee una estructura estándar para transportar documentos sobre una variedad de tecnologías estándar de internet, incluidas SMTP, HTTP y FTP entre otros. (4) JAXB Arquitectura java para relacionar documentos XML que provee una forma fácil y conveniente de unir esquemas XML con representaciones JAVA. (10) SAAJ SOAP with Attachments API for Java. Es utilizado por la mensajería que esta por detrás de escena en los handlers de JAX-WS. Tambien puede ser utilizado por los desarrolladores para escribir los mensajes de SOAP directamente. Esta API permite realizar mensajes XML desde la plataforma Java. (10) W3C World Wide Web Consortium, desarrolla tecnologías inter-operativas para guiar la red a su potencialidad máxima a modo de foro de información, comercio, comunicación y conocimiento colectivo. Descubra más sobre la oficina del W3C. (16) WSDL Web Service Description Language, es una tecnología XML que describe la interfaz de un servicio web de una forma estandarizada. Este estandariza como un servicio web representa los parámetros de entrada y salida de una invocación externa. WSDL permite diferentes clientes entender automáticamente como interactuar con un servicio web. (10)