UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIECIAS MATEMATICAS Y FISICAS

CARRERA DE INGENIERIA EN SISTEMAS
COMPUTACIONALES

TRABAJO DE
SISTEMAS OPERATIVOS

TEMA:
WEB SERVICE

AUTORES:
PEDRO RAMIREZ
MARTHA QUIJIJE
MC. HAMER
JOSE MORAN
JUSTIN DELGADO

CURSO:
S7-1

PROFESOR:
ING. JOSE PONCE GUERRERO

GRUPO 6
GUAYAQUIL – ECUADOR
INTRODUCCION

En el presente trabajo se investigará el tema de web services, en donde hablaremos

sobre la arquitectura, descubrimiento, políticas entre otras cosas las cuales
analizaremos, detallaremos y explicaremos en clases a los alumnos de séptimo semestre
acerca de los usos del web services como medio de comunicación cliente servidor.
Según los investigado nos damos cuenta de que los Servicios Web surgieron ante una
necesidad de estandarizar la comunicación entre distintas plataformas (PC, Mainframe,
Mac, etc.) y lenguajes de programación (PHP, C#, Java, etc.).
Web services, es un conjunto de protocolos y estándares que sirven para intercambiar
datos entre aplicaciones, en donde distintas aplicaciones de software desarrolladas en
lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden
utilizar los servicios web para intercambiar datos en redes de ordenadores como
internet.
Web services como sistema para comunicar utiliza XML estandarizado. En donde
emplea XML para llevar a cabo RPC, el cual es un protocolo de red que permite
ejecutar un código en una maquina remota.
En donde los Web Services tienen distintos compones necesarios para interactuar en una
comunicación, además de los protocolos utilizados a la hora de la utilización del
servicio.
La arquitectura del web service posee 4 servicios que son Discovery, Description,
invocation y transport, de las cuales hace uso para la comunicación, además
explicaremos de SOAP que es un protocolo de comunicación el cual es utilizado para
servicios web XML.
Al final después de haber presentado los conceptos a los estudiantes se dará a conocer
una práctica sencilla en donde se mostrará la conexión de un web servirce desde un web
service creado a partir de ISS y un cliente conectado por medio de Visual Studio.
Como conclusión podemos decir que los Web Services surgieron para finalmente poder
lograr la tan esperada comunicación entre diferentes plataformas, y además la
recomendación que se le podría dar a los estudiantes es que al momento de querer hacer
comunicaciones entre dos máquinas es necesario habilitar los puertos para evitar futuras
complicaciones.
1. OBJETIVOS
1.1 Objetivo General
Proporcionar conocimiento adquiridos a los alumnos del séptimo semestre acerca de
los manejos y usos dados al web service como medio de comunicación cliente -
servidor, así como las utilidades dadas dentro de un sistema distribuido.
1.2 Objetivos Específicos
 Consultar acerca de las características y aplicaciones dadas al web service.
 Emitir un corrector concepto para que los alumnos puedan tomar una
decisión clara del uso dado al web service dentro del campo laboral.
 Exponer de manera clara y precisa las ventajas del web service dentro de
una arquitectura de sistemas distribuidos para el correcto manejo de los
datos.

2. MARCO TEORICO
¿Qué es un web service?
Un web service es una
aplicación que puede ser
descripta, publicada, localizada
e invocada a través de una red,
generalmente Internet.
Combinan los mejores aspectos
del desarrollo basado en
componentes y la Web.
Al igual que los componentes,
los web services son
funcionalidades que se
encuentran dentro de una caja
negra, que pueden ser reutilizados sin preocuparse de cómo fueron implementados. A
diferencia de la actual tecnología de componentes, no son accedidos por medio de
protocolos específicos del modelo de objetos como ser RMI, DCOM o IIOP; sino que
son accedidos utilizando protocolos web como ser HTTP y XML.
La interface de los web services esta definida en términos de los mensajes que el mismo
acepta y retorna, por lo cual los consumidores de los web services pueden ser
implementados en cualquier plataforma y en cualquier lenguaje de programación, solo
tiene que poder crear y consumir los mensajes definidos por la interface de los web
services.
En pocas palabras Un servicio Web (Web service) es una colección de protocolos y
estándares que sirven para intercambiar datos entre aplicaciones. La interoperabilidad se
consigue mediante la adopción de estándares abiertos.
Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes
aplicaciones, que interactúan entre sí para presentar información dinámica al usuario.
Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al
mismo tiempo sea posible su combinación para realizar operaciones complejas, es
necesaria una arquitectura de referencia estándar.

Componentes de un Web Service

La arquitectura básica del modelo de web services describe a un consumidor, un
proveedor y ocasionalmente un corredor (broker). Relacionados con estos agentes están
las operaciones de publicar, encontrar y enlazar.
La idea básica consiste en que un proveedor publica sus servicios en un corredor, luego
un consumidor se conecta el corredor para encontrar los servicios deseados y una vez
que lo hace se realiza un lazo entre el consumidor y el proveedor.
Cada entidad puede jugar alguno o todos los roles.

Por todo lo anterior hay ciertos requerimientos a la hora de desarrollar o consumir un

web services:
 Una forma estándar de representar los datos.
XML es la opción obvia para este requerimiento.
 Un formato común y extensible de mensajes.
SOAP es el elegido en este caso; SOAP es un protocolo liviano para el
intercambio de información. Más adelante en este documento lo veremos con
más detalle.
 Un lenguaje común y extensible para describir los servicios.
 La opción en este caso es WSDL. Es un lenguaje basado en XML desarrollado
en forma conjunta por IBM y Microsoft. Lo veremos con más detalle mas
adelante en este documento.
 Una forma de descubrir los servicios en Internet.
UDDI se utiliza en este caso; el mismo especifica un mecanismo para publicar y
localizar los servicios por parte de los proveedores y consumidores
respectivamente. Se verá con más detalle mas adelante en este documento.

Arquitectura de los Web Services

 Service Discovery. Responsable de centralizar servicios web en un directorio
común de registro y proveer una funcionalidad sencilla para publicar y buscar.
UDDI se encarga del Service Discovery.
 Service Description. Uno de los aspectos más característicos de los web
services es que se autodescriben. Esto significa que una vez que se ha localizado
un Web Service nos proporcionará información sobre que operaciones soporta y
cómo activarlo. Esto se realiza a través del Web Services Description Language
(WSDL).
 Service Invocation. Invocar a un Web Service implica pasar mensajes entre el
cliente y el servidor. SOAP (Simple Object Access Protocol) especifica cómo
deberíamos formatear los mensajes request para el servidor, y cómo el servidor
debería formatear sus mensajes de respuesta.
 Transport. Todos estos mensajes han de ser transmitidos de alguna forma entre
el servidor y el cliente. El protocolo elegido para ello es HTTP (HyperText
Transfer Protocol). Se pueden utilizar otros protocolos pero HTTP es
actualmente el más usado.

Ventajas de los servicios web

 Aportan interoperabilidad entre aplicaciones de software independientemente de
sus propiedades o de las plataformas sobre las que se instalen.
 Los servicios Web fomentan los estándares y protocolos basados en texto, que
hacen más fácil acceder a su contenido y entender su funcionamiento.
 Permiten que servicios y software de diferentes compañías ubicadas en
diferentes lugares geográficos puedan ser combinados fácilmente para proveer
servicios integrados.
Inconvenientes de los servicios Web
 Para realizar transacciones no pueden compararse en su grado de desarrollo con
los estándares abiertos de computación distribuida como CORBA (Common
Object Request Broker Architecture).
 Su rendimiento es bajo si se compara con otros modelos de computación
distribuida, tales como RMI (Remote Method Invocation), CORBA o DCOM
(Distributed Component Object Model). Es uno de los inconvenientes derivados
de adoptar un formato basado en texto. Y es que entre los objetivos de XML no
se encuentra la concisión ni la eficacia de procesamiento.
  Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en
firewall cuyas reglas tratan de bloquear o auditar la comunicación entre
programas a ambos lados de la barrera.
¿Cómo funciona un Web Service?
 El Service Provider genera el WSDL describiendo el Web Service y registra el
WSDL en el directorio UDDI o Service Registry.
 El Service Requestor o la aplicación del cliente requiere un Web Service y se
pone en contacto con el UDDI para localizar el Web Service.
 El cliente, basándose en la descripción descrita por el WSDL, envía un request
para un servicio particular al Web Service Listener, que se encarga de recibir y
enviar los mensajes en formato SOAP.
 El Web Service analiza el mensaje SOAP del request e invoca una operación
particular en la aplicación para procesar el request. El resultado se escribe de
nuevo en SOAP en forma de respuesta y se envía al cliente.
 El cliente analiza el mensaje de respuesta SOAP y lo interpreta o genera un error
si ha habido alguno.

Componentes de los servidores en una aplicación web service

Web Service. Es el software o componente que realiza las operaciones. Si está escrito
en Java, estas operaciones se realizarán en lenguaje Java. Los clientes invocarán estas
operaciones enviando mensajes SOAP.
SOAP Engine. El Web Service no sabe interpretar SOAP requests y crear SOAP
responses. Para hacer esto hace falta un SOAP engine, un software que se encarga del
manejo de estos mensajes. Apache Axis es un ejemplo.
Application Server. Para funcionar como un servidor que puede recibir requests desde
diferentes clientes, el SOAP engine normalmente funciona dentro de un application
server. Este es otro software que proporciona un espacio libre para aplicaciones que han
de ser accedidas por múltiples clientes. El SOAP engine funciona como una aplicación
dentro del application server. Ejemplos son Apache Tomcat server, Java Servlet y JSP
container.
HTTP Server. Algunos application servers incluyen funcionalidades HTTP, por lo que
se pueden tener Web Services funcionando instalando simplemente un SOAP engine y
un application server. Sin embargo, cuando un application server carece de
funcionalidad HTTP es necesario también un HTTP server, más comúnmente llamado
Web Server. Es un software que sabe cómo manejar mensajes HTTP. Los dos más
populares en la actualidad son Apache HTTP Server y Nginx.
Web Services Protocolos
Un servicio Web o WebService es un servicio ofrecido por una aplicación que expone su
lógica a clientes de cualquier plataforma mediante una interfaz accesible a través de la
red utilizando tecnologías (protocolos) estándar de Internet.
Por ejemplo, una aplicación como Access está formada por un conjunto de componentes
que ofrecen una serie de servicios, como el acceso a datos, la impresión de informes, el
diseño de tablas...
La idea de los servicios es la misma, aunque éstos no tienen por qué estar en el mismo
ordenador que el cliente y además son accedidos a través de un servidor Web y de un
modo independiente de la plataforma, utilizando protocolos estándar (HTTP, SOAP,
WSDL, UDDI).
Ofrece un directorio de servicios en UDDI
internet Encontrar
Ofrece un modo de definir los servicios WSDL
Describir
Permite invocar métodos de los servicios SOAP
Invocar
Permite a los consumidores de servicios
XML y XML Schema
enviar y recibir mensajes a y de los
Datos
servicios.
Son protocolos abiertos de internet, dan HTTP, SMTP, TCP
soporte a las capas superiores Transporte
Tabla 1. Pila de protocolos de los WebServices
UDDI
Abreviación de Universal Description, Discovery and Integration. Es un directorio
distribuido que opera en la Web que permite a las empresas publicar sus Web Services,
para que otras empresas conozcan y utilicen los Web Services que publican, opera de
manera análoga a las páginas amarillas.
WSDL
Abreviación de Web Services Description Language, es un lenguaje especificado en
XML que se ocupa para definir los Web Service como colecciones de punto de
comunicación capaces de intercambiar mensajes. El WSDL es parte integral de UDDI y
parte del registro global de XML, en otras palabras, es un estándar de uso público (no se
requiere pagar licencias ni royalties para usarlo).
SOAP
Abreviación de Simple Object Access Protocol, es un protocolo de mensajería
construido en XML que se usa para codificar información de los requerimientos de los
Web Services y para responder los mensajes “antes” de enviarlos por la red. Los
mensajes SOAP son independientes de los sistemas operativos y pueden ser
transportados por los protocolos que funcionan en la Internet, como ser: SMTP, MIME
y HTTP.
XML
Abreviación de Extensible Markup Language. El XML es una especificación
desarrollada por W3C. Permite a los desarrolladores crear sus propios tags, que les
permiten habilitar definiciones, transmisiones, validaciones, e interpretación de los
datos entre aplicaciones y entre organizaciones.
Servicio de Transporte
Responsable del transporte de mensajes entre las Aplicaciones de red y los protocolos
en los cuales se incluyen protocolos tales como HTTP, SMTP, FTP, así como también el
más reciente Blocks Extensible Exchange Protocol (BEEP).
Para crear un servicio puede utilizarse cualquiera de los lenguajes disponibles en la
plataforma .NET.
Una vez creado el servicio, para conseguir que sea accesible por los consumidores, es
necesario describirlo utilizando un lenguaje estándar llamado WSDL (Web Service
Description Language).
Los clientes del servicio podrán estar creados en cualquier lenguaje y ejecutarse sobre
cualquier sistema operativo y hardware, lo único necesario es que sean capaces de
obtener y entender la descripción WSDL de un servicio.
Un archivo WSDL es, en realidad, un archivo XML en el que se identifica el servicio y
se indica el esquema para poder utilizarlo, así como el protocolo o protocolos que es
posible utilizar.
Una vez dispone de esta información, el cliente puede comunicarse con el servicio
utilizando protocolos como HTTP o SOAP (SOAP añade invocación de métodos a
HTTP, aunque es posible hacerlo con peticiones HTTP-GET y/o HTTP-POST en lugar
de SOAP).
Además de describir un servicio para que pueda ser utilizado por los clientes es
importante publicar el servicio de modo que pueda ser encontrado por clientes que no
conozcan necesariamente el componente que ofrece el servicio, pero que busquen un
servicio de sus características. Esto se logra mediante el estándar UDDI (Universal
Description, Discovery and Integration Registry). Realmente se trata de un servicio
mundial en el que los proveedores de servicios pueden registrarlos de modo gratuito.
Fig 1. Creación, registro, búsqueda y utilización de una WebService.
 ¿Por qué tantos protocolos?
Actualmente, al publicar un documento en un servidor web apenas es necesario tener en
cuenta las características del cliente (S.O., hardware, aplicaciones...). Esto es posible
gracias a que HTML y HTTP son un estándar mundial de diseño, solicitud y transmisión
de documentos. De este modo, el servicio web (www) es universal, es decir, accesible
desde cualquier cliente.
Para conseguir algo similar con los WebServices, Microsoft, IBM y otras empresas han
estado y están definiendo los protocolos comentados, los cuales permitirán describir un
servicio, publicarlo de modo que los clientes puedan localizarlo y utilizarlo...
A continuación, se comentan brevemente algunas alternativas a los protocolos
comentados:
 En el caso de HTTP y SOAP otras opciones (en este caso sustitutivas y/o
complementarias) son:
o Jabber, es un protocolo asíncrono de transporte (más ligero que HTTP).
o EbXML, está pensado para integración de servicios en soluciones B2B
(Business to Business).
o XML-RPC, está basado en HTTP-POST.
 En el caso de WSDL otras opciones son:
o RDF (Resource Description Framework), definido por el W3C. Es más
potente pero también más complejo que WSDL.
o DAML (DARPA Agent Markup Language), definido por la agencia de
defensa estadounidense (DARPA). Es también más potente pero más
complejo que WSDL.
 En el caso de UDDI existe una propuesta alternativa realizada por Microsoft e
IBM, llamada WS-Inspection Language.

WS-Coordination
Bajo este dar se describe un entorno que ofrecen unos protocolos para el control de las
aplicaciones. Estos protocolos pueden coordinar de forma segura las transacciones entre
distintas aplicaciones distribuidas.
Esta especificación se ha de tomar como un bloque de construcción que ofrece ciertos
servicios, pero normalmente no es por si sola capaz de satisfacer las necesidades de los
clientes, es por lo que se suele utilizar en conjunción con otras especificaciones (otros
bloquees) como WS-Secrit o WS-transaction para conseguir un entorno que se ajuste a
las necesidades.
El entorno creado por esta especificación permite la creación por parte del servicio de
un contexto sobre el cual propagar sus procesos hacia otros servicios y registrar los
protocolos de coordinación. El entorno permite a los flujos de trabajo y a otros tipos de
sistemas para coordinar integrar mediante la ocultación de sus protocolos no estándares
de coord8inacion (protocolos propios) y trabajar con los estándares para interoperar en
un entorno heterogéneo.
Los mensajes que trabajan en este tipo de entornos mantienen la información sobre el en
la cabecera mediante un elemento llamado <CoordinationContext>

WS-transaction
Esta especificación define los tipos de coordinación que son utilizados en el entorno
concretado en el punto anterior.
En la especificación se definen dos tipos de transacciones:
Transacciones atómicas (denominadas AT. Atomic Transaction)
Actividades empresariales (denominadas BA. Business Activity)
Como programador se tiene la opción de elegir cualquiera de ellas (o las dos) a la hora
de diseñar las aplicaciones y al igual que WS-Coordination WS- Transaction sirve como
bloque de construcción de aplicaciones que se pueden combinar con otros por ejemplo
con el propio WS-Coordination.
Transacciones atomicas
Una transacción atómica es usada para coordinar actividades de corta duración y que se
ejecutan en dominios de confianza. En su especificación se definen mecanismos para
crear enlaces entre sistemas transaccionales existentes y estos nuevos mecanismos,
permitiendo así su interoperabilidad.
Se las denomina atómicas, porque los procesos que se dan en ellas se deben cumplir sin
problema. Si en alguno de ellos surgiera algún problema de cualquier tipo, se procedería
a deshacer los procesos que estando dentro de esta transacción, se hubieran ejecutado
correctamente. Al terminar los procesos el coordinador pregunta por el resultado de
cada uno de ellos. Si alguno de los procesos indicadores le responde que no ha tenido un
final satisfactorio, o bien no le responde, el coordinador da la orden de deshacer todas
las acciones que se habían realizado durante las transacciones atómica. Si todos los
procesos responden que sus acciones han finalizado correctamente procede a la
aceptación de la transacción y a la aplicación de las acciones realizadas.
Las transacciones atómicas bloquean recursos tanto a nivel de datos (registros de bases
de datos ficheros) como físico (memoria) para realizar sus procesos. Así los procesos se
aseguran poder deshacer la acción en caso de recibir esta orden por parte del
coordinador.
Todas estas acciones se deben realizar de manera transparente al resto de aplicaciones o
de servicios que usen los sistemas que estén involucrados en la transacción.
Actividades empresariales
Las actividades empresariales se emplean para coordinar procesos de larga duración y
en las que se desea aplicar una lógica de negocio a los fallos es decir mecanismos para
tratarlos. A diferencia de las transacciones atómicas las actividades empresariales no
bloquean datos mientras realizan sus procesos (pueden ser largos), y además sus
consecuencias son irremediables una vez realizado el proceso, no hay manera de
deshacerlo (no hay forma de deshacerlo de modo automático, está claro que en
ocasiones es posible realizar la operación inversa).
Las actividades empresariales comparten los recursos permitiendo el acceso a estos por
cualquier otra aplicación en cualquier momento no como en las transacciones atómicas.
Al igual que se vio en el punto anterior la especificación de las actividades
empresariales define protocoles para facilitar la integración con los procesos de negocio
y flujos de trabajo ya existentes y poder interoperar.
Orquestación
Los servicios Web "exponen" las operaciones de ciertas aplicaciones o sistemas de
información. Consecuentemente, la combinación (composición) de varios servicios Web
realmente implica la integración de las aplicaciones subyacentes y sus funcionalidades
Cuando se hace uso de orquestación, un proceso central (que puede ser otro servicio
Web) lleva el control de los servicios Web implicados en la realización de una tarea y
coordina la ejecución de las diferentes operaciones sobre dichos servicios Web. Los
servicios Web orquestados no "conocen" (y no necesitan conocer) que están implicados
en un proceso de composición y que forman parte de un proceso de negocio de nivel
más alto. Solamente el coordinador central de la orquestación es "consciente" de la meta
a conseguir, por lo que la orquestación se centraliza mediante definiciones explícitas de
las operaciones y del orden en el que se deben invocar los servicios Web, tal y como se
muestra en la siguiente figura. La orquestación se utiliza normalmente en procesos de
negocio privados.
¿Por qué orquestar Servicios Web?
Los servicios Web se utilizan actualmente tanto dentro como fuera de los límites de una
organización. Los servicios Web se están convirtiendo en la tecnología común para
proporcionar puntos de integración entre las aplicaciones (tanto por vendedores de
grandes aplicaciones de empresa, como por negocios tradicionales de internet, como la
tienda electrónica Amazon.com o la máquina de búsqueda Google, que exponen
interfaces en forma de servicios Web para que dichas aplicaciones sean también
"integrables").
El siguiente paso lógico en el salto a un modelo centrado en servicios (Web) es la
orquestación de dichos servicios en nuevos procesos de negocio y servicios de más alto
nivel. Los servicios Web proporcionan una tecnología de interfaces común que unifica
el modelo de integración para todos los servicios independientemente de su origen. Los
beneficios de los servicios Web, tales como su descubrimiento en tiempo de ejecución y
su bajo acoplamiento, contribuyen a la orquestación de servicios Web proporcionando
un acercamiento al modelado y ejecución de procesos de negocio en tiempo real. La
idea es construir orquestaciones sin utilizar herramientas de programación tradicionales,
tales como C# o Java, con el objetivo de reducir el esfuerzo total de producir nuevos
servicios y aplicaciones basadas en servicios.
La orquestación de servicios Web pretende proporcionar una aproximación abierta,
basada en estándares, para conectar servicios Web de forma conjunta con el objetivo de
crear procesos de negocio de más alto nivel.

Web Service Addressing

Web Services Addressing (WS-Addressing) forma parte de la familia de
especificaciones relacionadas con los servicios web desarrolladas por el W3C. Los
impulsores de esta especificación fueron BEA Systems, IBM, Microsoft, SAP y Sun
Microsystems.

Esta especificación provee de un mecanismo por el cual se pueden identificar servicios

web y mensajes de servicios web independientemente del protocolo de transporte
utilizado. WS-Addressing define un espacio de nombres que se utiliza para identificar
servicios web.
Gracias a esta especificación es posible hacer que las peticiones a servicios web puedan
ser transmitidas a través de redes compuestas por nodos que realicen algún
procesamiento sobre el mensaje, como firewalls, gateways, etc., de manera que la
información de transporte sea independiente del protocolo utilizado para la transmisión
del mensaje.

Definición de WS-Addressing
 Web services addressing proporciona mecanismos neutrales, independientes de
la capa de transporte, para direccionar mensajes y servicios web.
 Define elementos de XML para referenciar servicios y facilitar el
direccionamiento punto a punto de los endpoints en los mensajes.
 Permite al sistema de mensajes dar soporte a la transmisión de mensajes a través
de redes que incluyen nodos con procesamiento, tales como gestores de
endpoints, cortafuegos y pasarelas de modo independiente a la capa de
transporte.

Necesidad de WS-Addressing
 SOAP es muy genérico: no hay información de direccionamiento en las
capacidades del núcleo.
 Interacción típica: petición – respuesta de HTTP
 Puede haber otros escenarios:
o Protocolos sin capacidades de direccionamiento
o Protocolo no proporciona facilidades de secuenciación

o Envío de respuestas a una localización alternativa

 WS-Addressing proporciona a la mensajería SOAP una hoja de ruta

 Independientemente de qué puertos, estaciones de trabajo, firewalls, etc.
atraviese un paquete en ruta a su último destino, llevando una hoja de ruta
incluida en él, todo aquel que se encuentre por el camino sabrá:
o De dónde viene
o (Dirección postal) La dirección a donde se supone que va

o (Att) La persona o servicio específico en esa dirección que se supone va

a recibirlo
o Dónde debería ir si no puede ser remitido como estaba previsto
  Todo esto lo incluye en la cabecera del mensaje SOAP (<soap:header>).
 WS-Addressing convierte a los mensaje en unidades autónomas de
comunicación

Web Service Reliable

Web Services Reliable Messaging (WS-RM) es un estándar OASIS que permite que dos
sistemas intercambien mensajes SOAP de forma segura. El objetivo de WS-RM es
garantizar la entrega de mensajes en caso como por ejemplo, cuando el punto final de
destino no está disponible temporalmente (por ejemplo, en el caso de un reinicio del
servidor) o cuando la vía de acceso del mensaje cruza varias conexiones de transporte, y
cualquiera de ellas puede fallar (por ejemplo, a través de un cortafuegos). WS-RM
ofrece mayor fiabilidad al utilizar el transporte HTTP pero tiene un impacto en el
rendimiento.

WS-RM sólo es aplicable al transporte HTTP. Si configura WS-RM en un flujo de

mensajes que utiliza el transporte JMS, los valores de WS-RM no se utilizan cuando se
despliega el flujo.

Los sistemas que implementan WS-RM retransmiten mensajes que no se han entregado
ni se ha acusado recibido de ellos satisfactoriamente e impide que se entreguen
mensajes duplicados al destino de la aplicación. WS-RM es un protocolo de servicios
web y puede utilizarse con WS-Security y WS-Addressing.
La mensajería segura tiene lugar entre dos puntos finales conocidos como el origen de
mensajería segura y el destino de mensajería segura. Antes de que se envíen los
mensajes, el origen seguro y el destino seguro realizan un intercambio de mensajes para
establecer una Secuencia. Una Secuencia se identifica mediante un identificador
exclusivo y comprende una secuencia de mensajes que se numeran a partir de uno. Si se
envía un grupo de mensajes en una secuencia se garantiza la fiabilidad de todos los
mensajes en dicha secuencia.

El origen de mensajería segura envía cada mensaje una o varias veces al destino de
mensajería segura. El destino vuelve a enviar el acuse de recibo para cada mensaje que
recibe para mostrar que el mensaje se ha recibido satisfactoriamente. Si el origen de la
mensajería segura no recibe un acuse de recibo conforme el destino ha recibido el
mensaje, envía de nuevo el mensaje hasta que se reciba un acuse de recibo.

Cuando el destino ha recibido satisfactoriamente todos los mensajes de una secuencia y

el origen ha recibido un acuse de recibo, el origen envía un mensaje TerminateSequence
para dar instrucciones al destino de que la secuencia del mensaje está completa.

Si el cliente está esperando mensajes que no se han entregado, éste puede iniciar una
solicitud WS-MakeConnectiont. WS-MakeConnection es una especificación que
describe cómo se pueden intercambiar los mensajes entre un servidor y un cliente
utilizando un canal de fondo específico del transporte. La solicitud MakeConnection del
cliente permite al servidor responder con los mensajes que están en la cola que el cliente
no ha recibido.
Conceptos de mensajerías, políticas y seguridad en los servicios WEB
Se define Servicio Web como una interfaz modulable que permite que se invoque, se
publique y se localice dentro de la red, Para ello emplea el intercambio de mensajes
de XML estandarizados.
Los Servicios Web se basan en estándares y protocolos abiertos. A continuación, se
describen los estándares de forma breve:
 EXtensible Markup Language (XML): Basado en marcas y etiquetas, es muy
frecuente el uso de este metalenguaje para crear otros lenguajes con entidad
propia.
 Simple Object Access Protocol (SOAP): Este protocolo permite realizar
intercambios de información entre diversas aplicaciones situadas en entornos
que están descentralizados y se encuentran distribuidas.
 Universal Description Discovery and Integration (UDDI): Se encarga de la
publicación, localización y enlazado de los Servicios Web. El principal objetivo
que tiene UDDI es permitir, mediante el uso de unos criterios de selección para
la búsqueda, el localizarse a las diferentes entidades de negocio
 Web Service Description Language (WSDL): Es el estándar que se utiliza
para describir un Servicio Web. Está basado en XML y permite especificar
cómo deben representarse los parámetros, tanto de entrada como de salida, en
una invocación de tipo externo al servicio.

Características
Se ofrece un repaso de las principales iniciativas, en forma de consorcios u
organizaciones, que están implicadas en los servicios Web en general y en el aspecto de
su seguridad en particular
Consorcio World Wide Web (W3C)
La W3C nace con un objetivo claro, ser un foro de discusión abierto y fomentar la
interoperabilidad en la evolución técnica que se produce en el mundo Web. En un
periodo de tiempo menor a diez años, se han generado más de cincuenta
especificaciones técnicas que están orientadas a la estandarización de la infraestructura
Web.
Se definen como objetivos a largo plazo en W3C:
 Acceso Universal. Permitir que el acceso a la web sea para todos. Realizando un
esfuerzo por las tecnologías que consideran las diferentes lenguas, culturas,
capacidades, educación, recursos disponibles o las disminuciones físicas o
psíquicas de cada uno.
 Web Semántica. Ofrecer y desarrollar avances en el mundo WEB que permitan a
los usuarios disfrutar del mejor uso posible de los recursos disponibles en la
web, adaptándolo a las necesidades de cada usuario.
 Web de Confianza. Crear un desarrollo web, que permita realizar desarrollo
manteniendo unos criterios comerciales y sociales adecuados.
OASIS (Organization for the Advancement of Structured Information Standards)
OASIS, es un organismo global muy centrado en temas de comercio electrónico. Es un
organismo sin ánimo de lucro. Oasis trata de establecer estándares de forma abierta y
mediante procesos ligeros aplicados por sus miembros, tratando temas referentes a la
seguridad, servicios Web, edición digital, tratamiento de XML, etc.
IBM/Microsoft/Verisign/RSA Security
Mediante un proceso de colaboración entre las principales compañías dentro del ámbito
IT, siendo encabezadas por Microsoft e IBM, se han propuesto una serie de
especificaciones acerca de como afrontar la seguridad en los servicios Web. Dentro de
este conjunto de especificaciones se encuentra la especificación WS-Security
estandarizada por OASIS.
WS-Security
La especificación WS-Security, describe la forma de asegurar los servicios Web en el
nivel de los mensajes, en lugar de en el nivel del protocolo de transferencia o en el de la
conexión. Para ello, tiene como objetivo principal describir la forma de firmar y de
encriptar mensajes de tipo SOAP. Las soluciones en el nivel de transporte actuales,
como SSL/TLS, proporcionan un sólido cifrado y autenticación de datos punto a punto,
aunque presentan limitaciones cuando un servicio intermedio debe procesar o examinar
un mensaje. Por ejemplo, un gran número de organizaciones implementan un corta
fuegos (firewall) que realiza un filtrado en el nivel de la aplicación para examinar el
tráfico antes de pasarlo a una red interna.
Como funciona WS-Security
WS-Security define la forma de conseguir integridad, confidencialidad y autenticación
en los mensajes SOAP. Se realiza de la siguiente manera:
 La autenticación se ocupa de identificar al llamador.
 WS-Security utiliza tokens de seguridad para mantener esta información
mediante un encabezado de seguridad del mensaje SOAP.
 La integridad del mensaje se consigue mediante firmas digitales XML, que
permiten garantizar que no se han alterado partes del mensaje desde que lo firmó
el originador.
  La confidencialidad del mensaje se basa en la especificación XML Encryption y
garantiza que sólo el destinatario o los destinatarios a quien va destinado el
mensaje podrán comprender las partes correspondientes.
 Se apoya en WS-Adressing para asegurar el no repudio.
WS-Policy
Es la especificación encargada de delimitar las diferentes políticas aplicables a los
servicios Web. Es de vital importancia a la hora de integrar los servicios Web, ya que si
presentan cierta complejidad, es muy necesario conocer los detalles del XML que lo
define, además de otros requisitos o capacidades adicionales.
Si se produce un intento de integrar un servicio sin conocer los detalles de su
implementación probablemente se esté evocando al fracaso. Por lo tanto, es muy
necesario realizar un estándar que defina las diferentes políticas a acordar. Sin él, los
desarrolladores quedarían expuestos a realizar desarrollos sin integración y difícilmente
escalables
Un marco de trabajo de políticas permitiría a los desarrolladores expresar las políticas
de los servicios de una forma procesable por las computadoras. La infraestructura de los
servicios Web puede verse ser mejorada para entender ciertas políticas y forzar su uso
en tiempo de ejecución.
WS-Trust
La especificación WS-Trust permite definir extensiones al estándar WS-Security con el
objetivo claro de dotar a este de nuevos mecanismos de seguridad. En esta
especificación se incluye el proceso de solicitud, emisión y control sobre tokens de
seguridad y se permite la gestión de las relaciones de confianza entre los servicios
WS-Security, realiza una definición amplia de los mecanismos básicos para
proporcionar un entorno de trabajo seguro en el intercambio de mensajes. Esta
especificación, partiendo de los mecanismos básicos, va añadiendo primitivas
adicionales junto con extensiones para estandarizar el intercambio de tokens de
seguridad. Con ello se busca optimizar la emisión y propagación de las credenciales de
los servicios dentro de diferentes dominios de confianza.
Como funciona WS-Trust
Esta especificación da soporte a un modelo de confianza destinado a los servicios Web,
se le denomina Web Services Trust Model. Para ello, define un proceso a través del
cual, un servicio, puede solicitar que cualquier petición que le llegue cumpla con una
serie de reclamaciones. En la situación, que un solicitante no disponga de todos los
requerimientos necesarios, los solicita al Servicio de tokens de seguridad (STS). Existe
una relación de confianza entre el STS y el servicio
La especificación define varios mecanismos para verificar relaciones de confianza entre
dos partes. Sin embargo, no se restringe solo a ellos, pudiendo un servicio verificar la
relación de confianza con la otra parte como considere necesario. Los métodos que
definen son los siguientes:
  Fixed Trust Roots: El más simple. El servicio mantiene un conjunto fijo de
relaciones de confianza
 Trust hierarchies: El servicio confiara en los tokens siempre que vengan de una
jerarquía de confianza que lleve a un trust root.
 Authentication Service: Es un servicio con el cual el servicio mantiene una
relación de confianza. Cuando llega un security token, el servicio lo envía al
Authentication Service el cuál enviará probablemente otro token que aprobará o
no la autenticación
WS-Federation
Con frecuencia se produce la situación de que participantes en el consumo y la
prestación de un servicio pueden utilizar diferentes tecnologías de seguridad, por
ejemplo, una de las partes podrá utilizar Kerberos y otro Certificados X.509, podría
necesitarse una traducción de los datos que afectan a la seguridad entre las partes
afectadas.
Una federación es una colección dominios de seguridad que han establecido relaciones
en virtud del cual un proveedor de uno de los dominios puede proporcionar acceso
autorizado a los recursos que gestiona sobre la base de la información de los
participantes (como puede ser su identidad) la cual debe ser afirmada por un proveedor
de identidad (Security Token Service).
WS-Federation es la especificación que describe la forma de llevar a cabo la
intermediación entre los participantes. Esta especificación tiene como objetivo principal
ayudar a la definición de los mecanismos de federación de dominios de seguridad, ya
sean distintos o similares. Para ello, define , categoriza y intermedia con los niveles de
confianza de las identidades, atributos, y autenticación de los servicios Web de todos los
colaboradores.
En la especificación WS-Federation se definen perfiles asociados a las entidades que
servirán para clasificar los solicitantes que pueden adaptarse al modelo. Es por tanto un
objetivo prioritario de esta especificación habilitar la federación de la información de las
identidades, atributos, autenticación y autorización.
WS-Addressing
WS-Addressing ofrece seguridad de extremo a extremo a la mensajería SOAP .
Independientemente de los tipos de intermediarios como puertos, workstations,
cortafuegos, etc. que sean atravesados por un bloque en el camino al receptor, todo
aquel que se encuentre por el camino sabrá:
 De dónde viene
 (Dirección postal) La dirección a donde se supone que va
 (Att) La persona o servicio específico en esa dirección que se supone va a
recibirlo
 Dónde debería ir si no puede ser remitido como estaba previsto
 Todo esto lo incluye en la cabecera del mensaje SOAP ()
  WS-Addressing convierte a los mensaje en unidades autónomas de
comunicación. La especificación WS-Addressing define dos tipos de elementos
que se incorporan en el mensajes SOAP:
 Endpoint References (EPR), referencias de invocación, que identifican al punto
donde deben ser dirigidas las peticiones.
 Message Information Headers, son cabeceras específicas que contienen
información relacionada con la identificación que caracteriza al mensaje.
La Seguridad en la Arquitectura de Referencia de los Servicios Web
Siguiendo el modelo W3C, vamos a realizar un pequeño estudio sobre los requisitos de
seguridad que se encuentran enumerados dentro de la arquitectura de referencia de los
servicios web y señalando las diferentes tentativas de ataque que también aparecen
dentro de la especificación. Se ofrecerán soluciones para las mismas.
Servicios de seguridad básicos
La seguridad es un concepto considerado clave dentro de los que comprenden el
aseguramiento de calidad dentro del servicio Web. Si se realiza una catalogación básica
de los servicios de seguridad son la confidencialidad, integridad, autenticidad de origen,
no repudio y control de acceso. A continuación, se explica brevemente cada uno de
ellos:
Autenticación de los participantes. Los servicios Web por definición tienen mucha
heterogeneidad, lo que provoca que los sistemas de autenticación tengan que ser
flexibles. Si imaginamos un servicio Web que necesita comunicarse con otro servicio,
este podría solicitar al demandante credenciales junto a una demostración de que es el
propietario de las mismas.
Autorización. Con frecuencia, es necesario aplicar unos criterios que permitan
controlar el acceso a los diferentes recursos. Es necesario definir los usuarios que
pueden realizar diversas acciones sobre los diferentes recursos. En combinación con la
autenticación, permite a las identidades conocidas realizar las acciones para las que
tienen permisos.
Confidencialidad. Es necesario asegurar que el contenido incluido en los mensajes que
se intercambian se mantiene como información confidencial. Es muy habitual emplear
técnicas de cifrado, ya muy extendidas. Obviamente, la confidencialidad del mensaje va
más allá que el canal por el que es transmitido.
Integridad. Esta propiedad garantiza que la información que se ha recibido es
exactamente la misma que se envió desde el cliente.
No repudio. En una comunicación que se realizan transacciones, es necesario registrar
que las mismas se han producido y registrar el autor que lo ejecutó. En el caso de los
servicios Web, trasladamos esta política el uso del servicio. Se comprueba que cierto
cliente hizo uso de un servicio a pesar de que éste lo niegue (no repudio del solicitante)
así como probar la ejecución se llevó a cabo (no repudio del receptor).
Disponibilidad. Uno de los ataques más frecuentes a las aplicaciones se basa en la
denegación de servicios. Se lanzan múltiples solicitudes falsas para inundar el servicio y
provocar su caída. Es necesario contemplar la disponibilidad, como punto muy
importante en el diseño de servicio web, ya que permiten cierta redundancia de los
sistemas.

Auditabilidad. El registro de las acciones en los servicios Web permite mantener una
traza de las mismas de manera que se puedan realizar análisis posteriores de los datos.
Seguridad extremo-a-extremo. Cuando se ejecuta un servicio es necesario garantizar
la seguridad durante todo el recorrido que efectúan los mensajes. Dado que
normalmente existen routers como intermediarios de la comunicación, esto provoca un
aumento de la política de seguridad que garantice que se realiza el transporte de forma
segura y confirme la seguridad de los intermediarios. Es importante disponer de un
contexto de seguridad único y que incluya el canal de comunicación.
Requisitos de Seguridad
Si realizamos una abstracción sobre la problemática, el objetivo principal es conseguir
un entorno para las transacciones y los procesos que sea seguro para todo el canal de
comunicación. Obviamente, es necesario garantizar la seguridad durante el tránsito de la
comunicación, ya sea con intermediarios o sin ellos durante la misma. Pro otra parte, se
necesita asegurar la seguridad de la información en los procesos de almacenamiento: A
continuación se ofrece una revisión breve de los principales requisitos para asegurar la
seguridad en la comunicación.
Mecanismos de autenticación
La autenticación es obligatoria para mantener control y verificar la identidad de
solicitantes y proveedores. En algunas ocasiones, resultará necesario realizar una
autenticación tanto del solicitante como del proveedor, ya que puede producirse que los
participantes no estén en conexión directa. Pueden existir intermediarios que
retransmitan la comunicación
En función de la política de seguridad que se adopte, será necesario autenticar tanto al
proveedor como al solicitante o simplemente a alguno de ellos. Se pueden emplear
métodos basados en contraseñas, certificados , etc.. para formalizar la autenticación. Si
se basan en contraseñas, es necesario aplicar una política que aporte robustez a las
mismas.
 Se pueden emplear mecanismos basados en protocolos de transporte como
el Http Autentication y SSL/TLS X509 Certificate. Estos mecanismos sólo son
válidos cuando existe una conexión directa entre el consumidor y el proveedor
de servicio, ya que si un mensaje SOAP viaja entre varios endpoints antes de
llegar a su destino, las credenciales del consumidor original se pierden en el
primer endpoint.
 También se pueden emplear mecanismos basados en tokens que se incluye
dentro del mensaje. El estándar WS-Security incorpora un gran número de
tokens que pueden ser empleados en este caso; Username Token, X509
Certificate, SAML assertions, etc. Este mecanismo de autenticación no tiene los
 problemas de los mecanismos basados en el transporte, ya que las credenciales
pueden viajar entre los distintos endpoints hasta llegar a su destino. Si usamos
este mecanismo, es necesario que estos sean transmitidos de forma segura para
evitar ataques de replay. Esto puede se consigue mediante la firma del
tokendentro del mensaje SOAP, junto a un TimeStamp o IDMessage, por lo que
se recomienda incluir en la firma la cabecera de WS-Addressing. En entornos
cerrados también se puede emplear SSL para transmitir los mensajes con Tokens
de forma segura, aunque esta aproximación es menos segura que la anterior.
Autorización
La autorización resulta necesaria para efectuar un control sobre el acceso a los recursos.
Una vez se ha realizado la autenticación sobre el participante y se conoce su identidad,
se utilizarán los mecanismos de autorización para realizar las comprobaciones
pertinentes y asegurar el acceso adecuado al recurso por parte del participante.
Integridad y confidencialidad de los datos
El proceso que mantiene la integridad de los datos, garantiza que la información que se
ha enviada no ha sufrido ninguna transformación sin que se haya detectado. La
confidencialidad, asegura los principios de intimidad de la información. Es decir solo se
permite el acceso a la información a aquellos participantes con permisos para hacerlo.
Con frecuencia, se usan técnicas de cifrado para conceptos de confidencialidad y la
firma digital para temas de integridad.
No repudio
El objeto de las técnicas de no repudio ya se han comentado anteriormente, es registrar
la participación y el grado de la misma de los diferentes interlocutores en una
transacción para protegerlo de una posible denegación, posiblemente por parte de algún
interlocutor de la misma, negando de que la transacción ocurrió o de su participación en
la misma.
Las técnicas de no repudio permiten proporcionar evidencias sobre lo sucedido en la
transacción, de manera que una tercera parte resuelve el desacuerdo producido.
Rastreabilidad
Es necesario ajustar trazas que aseguren poder conocer información del acceso una vez
se haya producido este, y comprobar el comportamiento que ha tenido el usuario que ha
realizado el acceso. Son de especial importancia para verificar la integridad del sistema.
Normalmente las trazas las generen los determinados "agentes de auditoria" que pueden
realizar monitoreo, observar recursos y el comportamiento de otros agentes, y validar el
cumplimiento de las políticas establecidas. Con frecuencia , no es posible prevenir la
violación de las diferentes obligaciones pero si un agente de auditoria detecta una
brecha podría activar un plan de repulsa o determinar otro tipo de actividades.
Aplicación distribuida de las políticas de seguridad
Si se han definido arquitecturas que están basadas en Servicios Web, están deben
permitir la definición de políticas de seguridad y comprobar su cumplimiento en las
diversas plataformas y con las diversas variaciones de acceso al servicio.
 Uso de políticas
Los mensajes que se envían en la comunicación de los servicios Web atraviesan los
cortafuegos y pueden ser modificados a través de los diferentes puertos y protocolos
existentes. Es necesario, para asegurar la calidad de seguridad en los servicios Web,
crear políticas corporativas para integrarse con las diversas políticas de los proveedores
y con la gestión de la confianza planificada.
Políticas distribuidas
Con frecuencia, se asocian las políticas de seguridad a los proveedores o a los clientes o
a un mecanismo de descubrimiento. Se utilizan para controlar y definir la metodología
de acceso de las peticiones y las respuestas a las mismas, dadas por los involucrados en
la comunicación. Estas políticas son validadas en ejecución dentro del contexto de la
comunicación. Cada parte involucrada debe realizar la validación de sus políticas.
Políticas de confianza
Defiendo de manera simple una política de confianza como una política distribuida que
asegura a dos entidades que afrontan una interacción sin conocerse previamente.
Mediante el uso de credenciales, asumen el nivel de seguridad que pueden soportar. En
ocasiones, la definición de estas políticas implica a terceras entidades de forma
recursiva, que influyen en la decisión. Un ejemplo, "yo confió en esta entidad, si mis
dos compañeros confían en ti y tu confías en mis dos compañeros"
Mecanismo de Descubrimiento Seguro
El mecanismo de descubrimiento seguro controla las publicaciones y apariciones de un
servicio. Cuando aparece un servicio, es necesario realizar una evaluación de las
políticas de publicación del servicio, exceptuando las situaciones que supongan un
servicio de descubrimiento entre nodos. Si el descubrimiento lo realiza un cliente, puede
dotar de identidad o no dársela al servicio. En esta segunda situación hablamos de un
descubrimiento anónimo.
Confianza y Descubrimiento
Si imaginamos una situación donde un cliente descubre que existe un servicio Web muy
necesario para él, y el proveedor del mismo, es una entidad desconocida hay que
preguntarse que nivel de confianza puede otorgar el solicitante a ese servicio. Esta
situación es especialmente importante en el caso que se este manejando información
muy sensible, ya que se esta corrigiendo un riesgo grave.
Privacidad
La privacidad se expresa mediante las diferentes políticas definidas por los diferentes
propietarios de los datos. Con frecuencia, los propietarios son los usuarios de los
servicios Web. Es necesario asegurar que los privilegios y derechos de los usuarios son
respetados
Fiabilidad de los servicios Web
La aparición de errores es inevitable, especialmente si consideramos que el contexto
engloba a multitud de servicios interconectados por una red global que pertenecen a
todo tipo de personas y entidades. La eliminación de errores no puede ser completa, así
que el objetivo principal es reducir la tasa de errores que aparecen al nivel máximo
posible.
Si hablamos de fiabilidad dentro de los servicios Web, podemos realizar una
clasificación en función de la predecibilidad y la fiabilidad de:
 Los servicios de la infraestructura, como un mecanismo de transporte de los
mensajes o un servicio de descubrimiento.
 Las interacciones entre los servicios.
 El comportamiento individual del solicitante y del proveedor.
Amenazas de seguridad
Si analizamos el concepto de amenaza de seguridad, tendemos a asumir que existirá un
intento de acceso y mal uso de los servicios. Por lo tanto hay que realizar un esfuerzo
para controlar los accesos no permitidos. Si realizamos una clasificación de las
principales amenazas, tenemos lo siguiente:
 Acceso no permitido llevado a cabo por entidades sin identificar. Es necesario
poder identificar de forma confiable la identidad de proveedores, servicios, etc...
 Alteración de la información en el canal de comunicación. Es necesario
garantizar la integridad de la información que se envía.
 Debe asegurarse el acceso a la información. Solo pueden acceder las partes
deseadas. Debe de mantenerse una certeza del contenido y de que la
comunicación tuvo lugar.
 El acceso inapropiado a los recursos. Debería ser posible garantizar que los
recursos y las acciones no son accesibles por aquellas partes que no están
autorizadas. De nuevo, este hecho se podría extender al mero conocimiento de
que cierto recurso existe, es decir, de alguna forma se debería poder impedir que
personas no autorizadas no puedan conocer la existencia de ciertos recursos o
ciertos servicios.
 Denegación de servicio. No debería ser posible que los clientes de los servicios
no puedan acceder a él.
Tipos de ataques
Los tipos de ataques que se listan a continuación están extraídos de la especificación
W3C.
Alteración de los mensajes
Es un tipo de ataque centrado sobre la integridad de los mensajes. Se busca modificar el
contenido del mensaje (ya sea parcialmente o totalmente). En el caso que el atacante
tuviera controlado un canal de comunicaciones entre servicios podría modificar los
mismos, eliminarlos, capturarlos y reenviarlos.
Ataques a la confidencialidad
Centrados en la captación de la información contenida dentro de los mensajes. En
ocasiones puede existir información muy sensible (datos médicos, datos económicos,
etc...)
Hombre en el medio o ‘man- in-the-middle.
Es la infiltración por parte de un atacante entre los participantes de una comunicación.
Normalmente, intercepta la comunicación y suplanta a los participantes de manera que
estos creen que se comunican entre si cuando lo hacen con el atacante.
La posibilidad de un ataque de intermediario sigue siendo un problema potencial de
seguridad serio, incluso para muchos sistemas criptográficos basados en clave pública.
Existen varios tipos de defensa contra estos ataques que emplean técnicas de
autenticación basadas en:
 Claves públicas
 Autenticación mutua fuerte
 Claves secretas (secretos con alta entropía)
 Passwords (secretos con baja entropía)
 Otros criterios, como el reconocimiento de voz u otras características
biométricas
 La integridad de las claves públicas debe asegurarse de alguna manera, pero
éstas no exigen ser secretas, mientras que los passwords y las claves de secreto
compartido tienen el requerimiento adicional de la confidencialidad. Las claves
públicas pueden ser verificadas por una autoridad de certificación (CA), cuya
clave pública sea distribuida a través de un canal seguro (por ejemplo, integrada
en el navegador web o en la instalación del sistema operativo).
Suplantación de identidad (Spoofing)
Es un ataque orientado a los niveles de confianza que se establecen en la comunicación.
El atacante suplanta la identidad de uno de los participantes en una relación de
confianza, usualmente trata de comprometer al destinatario de la comunicación. Es muy
útil utilizar una robusta autenticación para fortalecer el servicio ante estos ataques.
Denegación de servicio
El objetivo es mantener un servicio activo para que los usuarios legítimos puedan
acceder a él. Los ataques se centran en destruir la disponibilidad de un servicio. Su
objetivo es interrumpir las operaciones de un servicio dejándolo desconectado.
Es necesario adaptar la configuración del servidor a las necesidades de autenticación,
seguir recomendaciones con respecto al tamaño de mensajes aceptadas, controlar la
distribución de mensajes para minimizar este tipo de ataques.
Ataque de repetición
En este caso un atacante es capaz de interceptar un mensaje válido pudiendo reenviarlo
más tarde todas las veces que quiera al servicio para el que era destinatario. Para poder
solventar este problema se deben utilizar técnicas de autenticación apropiadas
conjuntamente con técnicas de sellado de tiempos y números de secuencia.
Estándares y frameworks actuales que abordan la seguridad en servicios web
El esquema del que parte la estructura de los servicios Web, tiene unas características
propias de acceso a la información, sobre el intercambio de la misma, sobre la
autonomía de la información que difieren de lo establecido en los modelos de seguridad
tradicionales. De hecho, esto provoca la necesidad y el desafío de modificar
mecanismos que afectan a la integridad y confidencialidad de la información que es
enviada por el canal del servicio Web. Si analizamos la estructura de los sistemas de
seguridad perimetrales (cortafuegos , sistemas anti-intrusos) no están preparados para
asegurar arquitecturas SOA. Estas arquitecturas son eminentemente dinámicas y son
transmitidas a través de protocolos no asegurados como HTTP. Si aplicamos criterios
que controlan la comunicación punto a punto (TLS,SSL), no son validos para porque no
aseguran la aplicación completa.
ANEXOS
Fotos

Pedro Ramírez

Martha Quijije
MC. Hamer

José Morán
 Justin Delgado

Video (investigación de campo)

https://drive.google.com/file/d/1oZjNX9inBo8STzeE1xV1jucKGke7LQNS/view
Dispositivas
BIBLIOGRAFIA
¿Qué son los servicios web? (2018). Obtenido de
https://msaffirio.wordpress.com/2006/02/05/%C2%BFque-son-los-web-services/
Besteiro, M., y Rodríguez, M. (2018). Obtenido de
http://www.ehu.eus/mrodriguez/archivos/csharppdf/ServiciosWeb/WebServices.pdf
Vargas-Solar, Genoveva, de Castro, Valeria, Souza Neto, Plácido Antonio de,
Espinosa-Oviedo, Javier A., Marcos, Esperanza, Musicante, Martin A., Zechinelli-
Martini, José-Luis, & Collet, Christine. (2014). Reliable Web Services Composition:
An MDD Approach. Polibits, (49), Obtenido de
http://www.scielo.org.mx/scielo.php?script=sci_arttext&pid=S1870-
90442014000100003&lng=es&tlng=en.
Ribas Lequerica, J. (2003). Web Services (Edicion Especial). ANAYA
MULTIMEDIA.
Universidad d' Alacant. (26 de junio de 2014). Dept. Ciencia de la Computación e
IA. Obtenido de http://www.jtech.ua.es/j2ee/publico/servc-web-2012-
13/sesion03-apuntes.html