Seguridad en comunicaciones de servicios Web

Santiago Hurtado

Universidad de los Andes

Facultad de Ingeniera
Departamento de Ingeniera de Sistemas
Bogot D.C. ,2008

Seguridad en comunicaciones de servicios Web

Santiago Hurtado

Proyecto de Grado
Director
Nicols Lpez

Universidad de los Andes

Facultad de Ingeniera
Departamento de Ingeniera de Sistemas
Bogot D.C. ,2008

Nota de aceptacin:
__________________________
__________________________
__________________________
__________________________
__________________________
__________________________
__________________________
__________________________

__________________________
Director de Proyecto
__________________________
Jurado
__________________________
Jurado

Tabla de contenidos
INTRODUCCIN ........................................................................................................................................... 6
MOTIVACIN ............................................................................................................................................... 7
OBJETIVOS ................................................................................................................................................... 8
OBJETIVO GENERAL ............................................................................................................................................. 8
OBJETIVOS ESPECFICOS ....................................................................................................................................... 8
CONTEXTO ................................................................................................................................................... 9
SEGURIDAD ........................................................................................................................................................ 9
Identificacin y autenticacin .................................................................................................................... 9
Autorizacin ............................................................................................................................................... 9
No repudiacin........................................................................................................................................... 9
Privacidad y confidencialidad .................................................................................................................... 9
Integridad .................................................................................................................................................. 9
Accountability ............................................................................................................................................ 9
SERVICIOS WEB (3) ........................................................................................................................................... 10
Propiedades ............................................................................................................................................. 10
Estndares de seguridad.......................................................................................................................... 11
JAX-WS ..................................................................................................................................................... 12
SISTEMAS DISTRIBUIDOS ..................................................................................................................................... 13
Modelo de referencia de procesamiento abierto y distribuido ................................................................ 14
ESCENARIOS DE CALIDAD........................................................................................................................... 15
AUTENTICACIN DE SERVICIOS ............................................................................................................................. 15
Descripcin............................................................................................................................................... 15
Escenario.................................................................................................................................................. 15
NO REPUDIACIN .............................................................................................................................................. 16
Descripcin............................................................................................................................................... 16
Escenario.................................................................................................................................................. 17
ACCOUNTABILITY .............................................................................................................................................. 19
Descripcin............................................................................................................................................... 19
Escenario.................................................................................................................................................. 19
TRANSPARENCIA ............................................................................................................................................... 21
Descripcin............................................................................................................................................... 21
Escenario.................................................................................................................................................. 21
DISEO ...................................................................................................................................................... 25
ARQUITECTURA ................................................................................................................................................ 25
Vista de despliegue .................................................................................................................................. 25
Vista funcional ......................................................................................................................................... 26
DISEO DETALLADO .................................................................................................................................. 29

DIAGRAMAS DE FLUJO ........................................................................................................................................ 29

No repudiacin......................................................................................................................................... 29
Autenticacin 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
Generacin de Artefactos ........................................................................................................................ 35
EXTENSIN 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
INTEGRACIN DE BO A OBJETOS XML ................................................................................................................... 37
CREAR ANOTACIONES......................................................................................................................................... 37
MEJORAR EL PARSEADO DE MENSAJES SOAP.......................................................................................................... 37
CONCLUSIONES .......................................................................................................................................... 38
BIBLIOGRAFA ............................................................................................................................................ 39
LISTA DE FIGURAS ...................................................................................................................................... 41
GLOSARIO .................................................................................................................................................. 42
SERVICIO WEB .......................................................................................................................................... 42
XML .......................................................................................................................................................... 42
SOAP ........................................................................................................................................................ 42
JAXB ......................................................................................................................................................... 42
SAAJ ......................................................................................................................................................... 42
W3C ......................................................................................................................................................... 42
WSDL........................................................................................................................................................ 42

Introduccin
En este documento se presentan los estndares de seguridad definidos por la industria para el
manejo de servicios Web XML, para luego presentar las tecnologas 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 cmo 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.

Motivacin
La globalizacin de las empresas ha generado la necesidad de tener sistemas distribuidos. Los
servicios web son una solucin posible para satisfacer esta demanda. Los servicios web cumplen el
rol de conectores entre diferentes sistemas de informacin; esta caracterstica trae muchos
beneficios, pero a su vez compromete la seguridad.
El inters en los servicios web esta en las caractersticas que ofrecen. Son portables, fiables y
soportan conexiones, tanto sincrnicas como asincrnicas. 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
comunicacin, estn abiertos en el firewall del servidor.
Es necesario que estos cumplan estndares de seguridad, dado que las comunicaciones pueden
estar comprometidas en el envi de mensajes con informacin sensitiva. Es importante subrayar
que la seguridad, no es nicamente el cifrado de los canales de comunicacin, tambin es
necesario incluir otros atributos que aseguren la calidad de los servicios ofrecidos; logrando
apoyar y asegurar la informacin.

Objetivos
Objetivo General
Construir un prototipo para proveer servicios web XML como componentes, el cual
cumpla los estndares de: seguridad, autenticacin, no repudiacin y auditoria,
proporcionando transparencia de acceso.

Objetivos Especficos

Identificar los estndares 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 comunicacin segura en sistemas distribuidos.
Definir escenarios de calidad de las propiedades de seguridad, para comprobar cmo los
servicios web los satisfacen.
Realizar el anlisis, diseo y definicin de una arquitectura objetivo para ser incluida con el
modulo de seguridad y lograr que las aplicaciones puedan ofrecer sus servicios de una
forma fcil y segura.
Construir un prototipo para la conexin entre la herramienta PlanningTool2 y el modulo de
seguridad, con servicios web con la tecnologa JAX-WS3 cumpliendo los estndares de
seguridad definidos.

Modelo de referencia de procesamiento abierto y distribuido RM-ODP proporciona un marco de

coordinacin para la normalizacin del desarrollo de aplicaciones abiertas y distribuidas.

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

Es una tecnologa diseada para simplificar la construccin de servicios web y clientes para servicios web.

Contexto
Seguridad
La seguridad de la informacin 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:
Identificacin y autenticacin
Verificacin de la identidad del usuario, proceso o servicio, como prerrequisito para confiar el
acceso a recursos en un sistema de informacin.
Autorizacin
Otorgar permisos para utilizar un recurso suministrado directa o indirectamente por una
aplicacin o el propietario de un sistema.
No repudiacin
Asegurar que el emisor reciba prueba de envi y el receptor prueba de identidad del emisor,
para que ninguno pueda negar tener la informacin y que esta sea correcta.
Privacidad y confidencialidad
Garantizar los procesos, polticas y controles utilizados para proteger la informacin, de
accesos sin autorizacin.
Integridad
Asegurar que la informacin no ha sido alterada de una manera no autorizada, la cual pueda
comprometer completitud, disponibilidad y precisin.
Accountability4
Observar eventos y archivarlos. Esta informacin debe estar disponible para ser verificada. Lo
cual permita reproducir acciones en un sistema. (2)

Responsabilidad

Servicios Web (3)

Los servicios web son componentes que hacen posible interactuar sistemas distribuidos y
procesos de TI heterogneos, los cuales pueden realizar desde las tareas ms sencillas hasta
las ms complejas. Estos son aplicaciones modulares auto contenidas, las cuales pueden ser
descritas, ubicadas e invocadas utilizando el mismo estndar web de transporte; que
necesitan un lenguaje comn para intercambiar datos, como lo es XML.
Al igual que los sistemas orientados por objetos, los conceptos fundamentales de los servicios
web son la encapsulacin, el envi de mensajes y la consulta y descripcin 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 mltiples beneficios, los cuales incluyen entre otros:

Promover la interoperabilidad, minimizando los requerimientos para compartir el

entendimiento entre los servicios.

Reducir la complejidad de la encapsulacin.

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 representacin, permite que los
sistemas heterogneos 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 caracterstica importante de diseo; 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 comunicacin sincrnica y asincrnica

Los servicios web pueden proveer comunicacin; sincrnica cuando sea necesario, pero la
capacidad de comunicacin asincrnica, 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 mtodos en
objetos remotos, utilizando un protocolo basado en XML.
Soporta intercambio de documentos
La ventaja clave de XML, es la forma genrica de representar documentos complejos. Los
servicios web, soportan el intercambio de documentos en forma transparente, para
facilitar la integracin de negocios.
Estndares de seguridad
En este proyecto nos vamos a enfocar en los estndares de seguridad en los mensajes SOAP5,
que nos ayudarn a solucionar los problemas de seguridad en autenticacin, no repudiacin y
auditoria en los servicios web.
Los estndares definidos, son independientes de las tecnologas 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. Tambin 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
Estndar definido por OASIS6 el cual provee las funciones bsicas, definiendo mecanismos
para asegurar: autenticidad, integridad y confidencialidad de los mensajes.
La especificacin propone un conjunto de estndares, para la extensin 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

Organization for the Advancement of Structured Information Standards (18)

Estndar definido por OASIS, que define un framework donde los servicios web, pueden
expresar las limitaciones y requerimientos, los cuales pueden ser expresados como
polticas que describen como los mensajes deben ser asegurados, incluyendo el nivel de
seguridad de transporte. La intencin es proveer suficiente informacin, a los
participantes para tener un intercambio seguro de mensajes. Este framework provee la
flexibilidad necesaria para definir estas polticas, con diferentes herramientas de
seguridad. (3)
WS-SecureConversation
Aunque la autenticacin es conveniente para mensajes simples o en una sola direccin.;
cuando es necesario intercambiar mltiples mensajes, es deseable establecer un contexto
de seguridad.
Es un estndar 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 desempeo de los intercambios de
mensajes posteriores. (3)
SAML7
Estndar definido por OASIS que extiende el estndar WS-Security, el cual provee medios
donde la autenticacin y las afirmaciones de autorizacin pueden ser intercambiadas
entre los servicios; logrando comunicar tokens de autenticacin 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 tecnologa incluida en la plataforma JEE59 diseada para simplificar la construccin 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 tecnologas definidas por W3C (11)

Security Assertion Markup Language

Java API for XML Web Services

Java Platform, Enterprise Edition 5

Incluye la arquitectura, para realizar la vinculacin de XML JAXB10 y el API SAAJ11. Adems
ayuda a acelerar la creacin 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 definicin de la especificacin 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.
Cdigo 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. Adems es bastante til cuando la implementacin de Java ya existe.

Sistemas distribuidos
El crecimiento del desarrollo de servicios web y los estndares en busca de soporte de la
automatizacin e integracin de negocios, ha conducido a grandes avances tecnolgicos en el rea
de integracin de software, especialmente en SOA 13 . El propsito de esta arquitectura es
solucionar los requerimientos de bajo acoplamiento, basados en estndares y computacin
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

Tecnologas de informacin

Modelo de referencia de procesamiento abierto y distribuido

El objetivo de la estandarizacin de ODP15 es el desarrollo de estndares, que permiten los
beneficios de distribuir servicios de procesamiento de informacin, en un ambiente
heterogneo de recursos de TI y mltiples dominios en las organizaciones.
Estos estndares dirigen las limitaciones en un sistema de especificacin y suministro de la
infraestructura, que acomoda las dificultades inherentes en el diseo y programacin de
sistemas distribuidos. (14)
Los elementos fundamentales de este estndar son:

Enfoque en la modelacin de objetos, para especificacin de sistemas.

Especificacin de un sistema, en trminos de especificaciones de puntos de vista,
separados pero inter relacionados.
La definicin de una infraestructura, que provea transparencias distribuidas para
aplicaciones de sistemas.
Un framework para la evaluacin de conformidad de los sistemas.

Transparencia de distribucin
La transparencia en distribucin permite que las complejidades asociadas, con sistemas
distribuidos, sean ocultadas en las aplicaciones donde son irrelevantes para su propsito.
Transparencia en acceso
Disfraza, las diferencias de representacin e invocacin de mecanismos para servicios
entre sistemas. Esta transparencia, soluciona muchos de los problemas de colaboracin
entre sistemas heterogneos y generalmente es suministrada por defecto.
Transparencia en ubicacin
Disfraza la necesidad de una aplicacin, para tener informacin acerca de la ubicacin e
invocar el servicio. Esta transparencia provee un nombramiento independiente a la
ubicacin fsica.

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 utilizacin remota de los servicios que suministra. Para que un
conector sea adecuado debe tener formas de conectarse al servidor, sin importar su ubicacin.
Se seleccionaron los servicios web para este trabajo, por su bajo acoplamiento y por su
portabilidad e interoperabilidad con otros lenguajes.
Es importante sealar, que se escogi la tecnologa JAX-WS por su fcil implementacin sobre
servicios Java ya diseados, dado que se pueden utilizar anotaciones en las interfaces y no debe
ser modificado el cdigo ya existente.
Los servicios web XML tienen varios niveles de comunicacin, en los que se pueden aplicar
modelos y estndares 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 estndares como WS-Security para permitir seguridad a nivel del intercambio de mensajes,
lo cual permite que los atributos de calidad sean cumplidos.

Autenticacin de servicios
Descripcin
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 transaccin
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 generacin
de certificados digitales, que cumplen con los estndares de WS-Security y WS-Trust,
adicional a esto provee un servicio de verificacin de certificados, los cuales fueron
proporcionados por el modulo de seguridad.

FIGURA 1, ESTRUCTURA AUTENTICACIN DE SERVICIOS

Protocolos
Se muestra el proceso en la figura 2. Cuando el consumidor desea utilizar servicios, enva
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 polticas, se niega la solicitud del servicio.

FIGURA 2, PROTOCOLO AUTENTICACIN DE SERVICIOS

No repudiacin
Descripcin
La no repudiacin 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 recepcin desde cada
servicio, pero su eficacia es altamente cuestionable, dado que puede existir un intermediario
que genere ambos y modifique la informacin.
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 repudiacin, es mediante el uso de
seguridad a nivel de la capa de transporte.
Escenario
Un servicio intercepta la informacin 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 informacin es incorrecto, ambos servicios descartan haber enviado y recibido el
mensaje.

Fuente: Usuario malintencionado intercepta y modifica informacin.

Estimulo: Transaccin interceptada
Artefacto: Modulo de seguridad, Servicio Proveedor y Servicio consumidor
Ambiente: Una vez se pide la informacin al proveedor, se suplanta el servicio y se
provee informacin 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
expedicin y verificacin de certificados, al igual que el escenario de calidad de
autenticacin.
Adicional a esto, debe proveer un servicio para recibir y enviar las pruebas de envi y
recepcin de mensajes. Este servicio es la base del aseguramiento de la no repudiacion,
donde el modelo provee prueba de origen obligatoria y prueba de recepcin obligatoria,
con el uso del modulo de seguridad como intermediario. Las pruebas de envi y recepcin
no son intercambiadas, hasta tanto el proveedor y el consumidor del servicio no hayan
enviado su prueba de envi y recepcin. Para esto se deben utilizar los estndares 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
cdigo.

FIGURA 3, ESTRUCTURA GENERAL NO REPUDIACION

Para asegurar que en los servicios de proveedor y consumidor esto suceda, se deben
establecer polticas para el intercambio de mensajes. Estas polticas pueden ser definidas
en el WSDL de los servicios y/o utilizando los clientes intermedios que garantizan que
estas polticas sean cumplidas. Debido a que se utilizan los estndares de la industria, se
podra 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 polticas.

FIGURA 4, ESTRUCTURA NO REPUDIACIN

Protocolos
El consumidor solicita informacin; el proveedor se la suministra y enva una prueba al
modulo de seguridad. El usuario o servicio mal intencionado intercepta la informacin y la
modifica, luego la reenva al consumidor; una vez el consumidor recibe la informacin,
enva una prueba de recepcin del mensaje. El modulo de seguridad verifica los

certificados y las pruebas de envi/recepcin, dado que no corresponden, enva un

mensaje de error a ambos servicios (figura 5).

FIGURA 5, PROTOCOLO NO REPUDIACIN

Accountability
Descripcin
Se puede reconstruir la informacin necesaria, para tener un servicio o un usuario
responsable, de las acciones realizadas dentro del sistema.
En la seguridad uno de los atributos ms 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 informacin
de los registros sea til, se debe lograr y analizar esta informacin. Si se tiene mucha
informacin no ser posible entenderla o tomar demasiado tiempo. Si es muy poca o
inexacta la informacin no servir de nada, ms que para ocupar espacio en el sistema.
Escenario
La perdida de informacin, hace evidente una vulnerabilidad del sistema; para lograr corregirla
se debe encontrar la fuente de esta modificacin. Para encontrarla es importante tener
informacin de quien realizo la modificacin y cuando, logrando que con esta se reduzca en lo
posible el origen de la inconsistencia.

Fuente: Servicio o persona que encuentra informacin inconsistente o modificada.

Estimulo: Solicitud de revisin de informacin inconsistente o modificada
Artefacto: Modulo de seguridad
Ambiente: Bajo operaciones normales
Respuesta: Se encuentra la fuente que modifico la informacin afectada en el servicio.
Medida: Se reducen al 5% los usuarios que pudieron modificar la informacin

Estructuras

Esta estructura bsica (figura 6), es la misma que se utiliza en la no repudiacin para la
recepcin de las pruebas de envi y recepcin 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 informacin almacenada, para
su uso posterior. Para el anlisis de la informacin ste debe ser extensible a nuevas
funcionalidades segn sea necesario.

FIGURA 7, ESTRUCTURA ACCOUNTABILITY

Protocolos
Los protocolos en la auditoria son dos: uno para recepcin de informacin(figura 8) y otro
para el anlisis y envi de informacin solicitada. Es necesario incluir el modelo de
seguridad de autenticacin, para que el uso de esta informacin sea apropiado.
Cada servicio en sus polticas 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
Descripcin
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 tambin 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 comunicacin. 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 diseo, puede
proveer diferentes protocolos de comunicacin segn sea oportuno. En nuestro caso se
agregaron conexiones a servicios web para que el modulo de seguridad pueda ser utilizado
desde cualquier ubicacin. 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
automtica 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 ubicacin 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
ubicacin segn 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 sesin, del modulo de seguridad. Pero para lograr acceder de forma externa
este no logra comunicarse por causa del firewall del servidor principal.
La solucin propuesta, es que el conector tenga un servicio de comunicacin 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. Automtico
Beneficios:
El usuario no necesita conocer los aspectos tcnicos, sobre el servicio que necesita. Se
conecta en orden de obtener la mejor forma de conexin.
16

Remote Method Invocation

Desventajas:
La conexin del servicio puede demorarse, mientras prueba las diferentes formas de
realizar esta conexin.
Descripcin:
El usuario solicita el servicio. El conector, selecciona la forma predeterminada para
establecer la conexin; 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 conexin con el servicio es mucho ms veloz
Desventajas:
El usuario debe entender, como se configura y las ventajas y desventajas de la forma de
conexin que va a utilizar.
Descripcin:
El usuario configura la manera como se va a conectar al servicio; solicita conexin si
funciona, continua normalmente, si no, muestra el error en la herramienta.

FIGURA 11, PROTOCOLO OPCION 2 TRANSPARENCIA

Diseo
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 recepcin y
envi de pruebas.
Los certificados son necesarios para autorizar el uso de servicios y para el manejo de no
repudiacin. Tambin para la no repudiacin y la auditoria se puede observar que comparten la
estructura de recepcin 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
Descripcin
La vista de despliegue muestra, cmo deben ser desplegados los diferentes mdulos para
utilizar la aplicacin.
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
sesin.
En el servidor de aplicaciones podemos observar tres mdulos:

El modulo de seguridad
Provee los servicios de autenticacin de usuarios.

El modulo de certificados
Expide y verifica la validez de estos certificados. Adems utiliza los servicios del
modulo de autenticacin 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 recepcin y envi de informacin,
que debe ser auditada. Para lo que tambin 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.
Tambin 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

Descripcin
Para cumplir con los estndares, de seguridad de autenticacin y no repudiacin se van a
proveer dos servicios principales. La expedicin de certificados y la verificacin de estos,
los cuales utilizan los servicios, que requiere asegurar la comunicacin.
Componentes funcionales

certificateExpedition: Servicio que expide certificados a las herramientas, las cuales

estn 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 verificacin.
certificateMatch: Servicio que compara dos certificados.

Accountability

FIGURA 14, VISTA FUNCIONAL ACCOUNTABILITY

Descripcin
Para lograr cumplir con la no repudiacin y accountability se proveen los servicios de este
modulo.
Componentes funcionales

storeLogInfo: Servicio que almacena la informacin.

storeSendProof: Servicio que almacena la prueba de envi
storeReceiptProof: Servicio que almacena la prueba de recepcin

Vista para no repudiacin

FIGURA 15, VISTA FUNCIONAL DE NO REPUDIACIN

Diseo detallado
Diagramas de flujo
No repudiacin

FIGURA 16, DIAGRAMA DE FLUJO DE NO REPUDIACIN

Autenticacin de Servicios

FIGURA 17, DIAGRAMA DE FLUJO DE AUTENTICACIN 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 fcilmente 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 conexin, por medio de la configuracin de este.

FIGURA 19, DIAGRAMA DE CLASES DEL CONECTOR

Certificados
El servidor de certificados tiene la complejidad en la capa de sesin, donde debe crear y
almacenar los certificados para su posterior uso, adicionalmente al expedir los certificados,
debe verificar con el componente de autenticacin 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 ubicacin. Es deseable
implementar un handler que provea el servicio de cifrado de mensajes, para aumentar la
seguridad que provee este modulo. El cifrado debera 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 sesin de dos servicios
principales: uno para almacenar logs y otro para la no repudiacin; este servicio es el
encargado de verificar las pruebas de envi y recepcin para luego proveerlas al servicio
proveedor y consumidor. Tambin se puede crear un jar con los handlers para ser distribuido a
los servicios, que requieran proveer la no repudiacin.
Es importante tener en cuenta que estos servicios pueden y es deseable que se utilicen junto a
la autenticacin 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 ms informacin, 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 sesin, 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 bsicas para crear un servicio web son:

@WebService
Esta anotacin declara la clase como un servicio web.
@WebMethod

Esta anotacin es utilizada para indicar, cuales mtodos van a ser expuestos por el servicio
web y tiene parmetros opcionales.
@HandlerChain
Anotacin 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 autenticacin
de servicios.

FIGURA 23, HANDLER CHAIN

WSDL
Para extender el archivo bsico 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 construccin 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 conexin con el servicio web y luego se pide
el puerto de sesin para obtener conexin, con la interfaz del SecurityWebServiceSession y as
poder utilizar los servicios del servicio web. En las siguientes lneas de la figura 24 podemos
observar cmo se agrega un handler a la cadena de handlers, aunque se puede hacer con
anotaciones, para el propsito del prototipo se utiliza de esta manera.
Generacin 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 generacin 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 anlisis de la
informacin, sin necesidad de realizar esta transformacin por medio de parsers.

Extensin 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 mtodo principal, handleMessage que provee
la facilidad de modificar estos mensajes antes de ser enviados al servicio o al recibirlos.

FIGURA 26, EXTENSIN 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 especificacin predeterminada para

realizar este parseado, es por medio de SAAJ, pero se puede utilizar cualquier otro mtodo 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
estndares WS-Security. En la figura 27 mostramos un mensaje soap despus de ser procesado por
el handler.

FIGURA 27, MENSAJE SOAP

En la figura 28 mostramos un ejemplo del handler de servidor de autenticacin de servicios, donde

se verifica el encabezado de seguridad y se obtiene la informacin 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 definicin del
estndar 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 informacin en la capa de transporte ya que esto da
seguridad adicional en las comunicaciones de los mensajes. Tambin provee una transparencia en
el manejo de la seguridad. Esta seguridad puede ser exigida por medio de polticas en el
documento WSDL, agregada en cada mensaje por medio del uso de handlers o por el cliente o
servicio web.

Integracin de BO a objetos XML

Dado que al generar el cdigo del cliente se crean objetos JAXP, es necesario convertirlos de
nuevo a Business Objects. Sera 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 ms 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
manipulacin. Se recomienda revisar tecnologas 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 POJOs y la generacin de cdigo mediante sus herramientas.
Es tan flexible que tambin 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 solucin.
Gracias a esta flexibilidad, los estndares de seguridad en los mensajes pueden ser implementados
en los servicios web. Para poder implementar estos estndares, 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 tecnologas no necesite crear lgica 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 cdigo adicional y la infraestructura necesarios para proveer la seguridad, al
implementar nuevos servicios web.

Bibliografa
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 lnea] 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 lnea] 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 lnea] 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 lnea] 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 lnea] 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 lnea] 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: 819366910.
11. Balani, Naveen y Hathi, Rajeev. Design and develop JAX-WS 2.0 Web services. International
Business Machines Corp. [En lnea] 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 lnea] septiembre de 2005. [Citado el: 20 de
septiembre de 2008.]

14. INTERNATIONAL STANDARD. Information technology Open Distributed Processing

Reference model: Overview. [En lnea] 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 lnea] [Citado el: 29 de 11 de 2008.] http://www.w3c.es/.
17. Oasis Standards. [En lnea] 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 lnea] 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 lnea] 2008. [Citado el: 10 de Noviembre de
2008.] http://www.oasis-open.org/who/.

Lista de figuras
FIGURA 1, Estructura autenticacin de servicios ---------------------------------------------------------------- 16
FIGURA 2, Protocolo autenticacin de servicios ----------------------------------------------------------------- 16
FIGURA 3, estructura general no repudiacion -------------------------------------------------------------------- 18
FIGURA 4, estructura no repudiacin------------------------------------------------------------------------------- 18
FIGURA 5, protocolo no repudiacin ------------------------------------------------------------------------------- 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 repudiacin ------------------------------------------------------------------- 28
FIGURA 16, diagrama de flujo de no repudiacin --------------------------------------------------------------- 29
FIGURA 17, diagrama de flujo de autenticacin 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, Extensin 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 lgica del negocio, ubicada en alguna parte en internet, la
cual es accesible a travs de protocolos de internet como HTTP o SMTP. Estos se diferencian
de otras tecnologas dado que el se basa en XML (4)
XML
Extensible Markup Language, es un estandar aprobado por W3C. Define una sintaxis genrica
utilizada para apuntar informacin con simples etiquetas. Este formato es suficientemente
flexible para ser personalizado para diversos dominios. (15)
SOAP
Simple Object Access Protocol, provee una estructura estndar para transportar documentos
sobre una variedad de tecnologas estndar de internet, incluidas SMTP, HTTP y FTP entre
otros. (4)
JAXB
Arquitectura java para relacionar documentos XML que provee una forma fcil y conveniente
de unir esquemas XML con representaciones JAVA. (10)
SAAJ
SOAP with Attachments API for Java. Es utilizado por la mensajera que esta por detrs 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 tecnologas inter-operativas para guiar la red a su
potencialidad mxima a modo de foro de informacin, comercio, comunicacin y
conocimiento colectivo. Descubra ms sobre la oficina del W3C. (16)
WSDL
Web Service Description Language, es una tecnologa XML que describe la interfaz de un
servicio web de una forma estandarizada. Este estandariza como un servicio web representa
los parmetros de entrada y salida de una invocacin externa. WSDL permite diferentes
clientes entender automticamente como interactuar con un servicio web. (10)