SOAP.- Simple Object Access Protocol (SOAP), es un protocolo estándar para el intercambio de
información estructurada por medio de XML, siendo de fácil entendimiento para el ser humano. Lo mensajes SOAP se transportan encapsulados por medio de otros protocolos como SMTP, HTTP, etc. Los mensajes tanto de petición como de respuesta contienen las siguientes partes (Figura 19): • Envelope.- Este elemento es obligatorio en el mensaje, contiene los otros dos elementos
del mensaje. Aquí se declara todos los namespace de los atributos adicionales.
• Header.- Este elemento es opcional, es decir que puedo o no estar presente en el mensaje, contiene información sobre el procesamiento del mensaje durante el acceso al mensaje, como tokens de seguridad, control de cabeceras, etc.
• Body.- Elemento obligatorio, contiene los datos del mensaje, aquí se especifica el intercambio de información entre el remitente y destinatario del mensaje SOAP.
La utilización de SOAP tiene como ventajas el no estar asociado a ningún lenguaje ni a ningún protocolo y permitir interoperabilidad. En la Figura 19 podemos ver un ejemplo de SOAP Request y SOAP Response del servicio web implementado en el presente trabajo. Cabe mencionar que este servicio estás sin seguridades.
57 Figura 19. Ejemplo de SOAP Request y SOAP Response
Fuente: Autor Elaboración: Autor
WSDL.- Web Services Description Language (WSDL), es el lenguaje de descripción de servicios
web, su ubicación, sus operaciones, argumentos, protocolos de comunicación y cómo acceder al servicio en la red. El WSDL es un documento XML con el cual una aplicación cliente puede leer éste documento para acceder a sus operaciones funcionando como contrato entre el cliente y servicio.
Este documento WSDL es un conjunto de definiciones que el autor (Ordóñez León, 2010) en su trabajo menciona (Figura 20):
• Tipos <types>.- Contiene las definiciones de los tipos de datos usados en el mensaje, por ejemplo XSD que es un tipo de datos definidos por XML Schema.
• Mensajes <message>.- Contiene información necesaria de los mensajes para realizar una operación de entrada y salida. Cada mensaje está compuesto por partes y cada parte tiene su nombre y su tipo de datos definidos anteriormente.
• Operación <operation>.- Define las acciones de los mensajes SOAP, es el conjunto de mensajes intercambiados de entrada y salida.
• Tipo de puerto <portType>.- Se define las operaciones permitidas y los mensajes que se utilizan para realizar la operación. Un tipo de puerto es una agrupación lógica de operaciones relacionadas entre sí.
58
• Bindings <binding>.- Describe como se utiliza el portType con un protocolo de transporte determinado como HTTP o SMTP, así como el estilo de transporte como RPC o Document. • Puerto <port>.- Asocia el binding con el punto de conexión del servicio (URI) donde se
puede acceder al servicio.
• Servicio <service>.- Un servicio define un tipo de puerto con un Binding a través de una dirección. Define los puntos o puertos finales de los bindings.
Figura 20. Estructura de documento WSDL
Fuente: (McDonald, 2009) Elaboración: Autor
WS-Security.- La especificación WS-Security emitida por OASIS provee de un conjunto de
estándares para la mensajería SOAP para la construcción de servicios web seguros, garantizando la confidencialidad e integridad de los datos y la autenticación de los mensajes. Integra tecnologías como PKI, SAML, XML Signature y XML Encryption, asegurando la interoperabilidad en cualquier plataforma.
Cabe recalcar que la implementación de WS-Security tiene como efecto una sobrecarga en el rendimiento y desempeño debido a la sobrecarga de los mensajes, al aumento de su tamaño requieren de mayor memoria, de procesamiento más rápido y de mayor ancho de banda. Pero todos estos costes se justifican cuando se requiere de una aplicación segura.
WS-Security provee un modelo unificado de cómo utilizar mecanismo de seguridad existente para autenticación, confidencialidad e integridad de los servicios web, para nuestro estudio utilizaremos SAML para la autenticación de los clientes que acceden al servicio web mediante certificados
Serv ice
Port
PortType Binding
Operation
59
X.509, que se describirá más adelante. En la Figura 21 podemos observar cómo es el flujo de mensajes mediante WS-Security.
Figura 21. Flujo de mensajes mediante WS-Security
Fuente: (Senmartí, 2010) Elaboración: (Senmartí, 2010)
Donde el cliente envía una petición solicitando los tokens necesarios para la seguridad en la comunicación; el Security Token Service valida estas peticiones enviadas al web service
mediante Kerberos o certificados X.509 y añade los tokens a las cabeceras del mensaje SOAP, de
tal modo que se implementa una firma digital en la cabecera del mensaje que incluye la información necesaria, garantizando así la integridad, confidencialidad y el no repudio para responder al
cliente.
WS-Interoperability.- Web Service Interoperability Organization (WS-I) es el encargado de
asegurar la interoperabilidad entre las distintas tecnologías que se implementan en SOAP. Este estándar toma en cuenta las siguientes consideraciones (Ordóñez León, 2010):
• Identificación y autenticación de las partes.
• Identificación y autenticación de los datos de origen. • Integridad de los datos.
• Confidencialidad de los datos. • Unicidad de los datos.
SAML.- Security Assertions Markup Language (SAML) especificación definida por OASIS, define
un esquema para XML para el intercambio de información que permite la autenticación entre dominios de seguridad en aplicaciones distribuidas. SAML proporciona tokens de seguridad que contienen aserciones o afirmaciones por las cuales las partes interesadas (usuarios finales y servidor) pueden comunicarse. Google es una de las empresas que utiliza autenticación SAML en sus aplicaciones como Gmail o Google Calendar.
Cliente Web Serv ice Security Token
Serv ice
Web Serv ice
Enviar petición de tokens
Recibir Tokens para añadir al mensaje SOAP
Respuesta Firmar y enviar mensaje
60
En la Figura 22 se puede observar el proceso de funcionamiento de la autenticación mediante SAML:
Figura 22. Autenticación SAML
Fuente: (Jitta, 2012) Elaboración: Autor
Donde se el usuario a través del navegador solicita un recurso HTTP al proveedor del servicio,
éste lleva a cabo un control de seguridad en nombre del recurso de destino, re direccionando la petición al proveedor de identidad, el cual solicita al usuario sus respectivas credenciales (tales como usuario y contraseña), que son enviadas al proveedor del servicio; El proveedor de
identidad al validar correctamente estas credenciales del usuario se crean aserciones SAML
integradas al navegador devolviendo una respuesta correcta al usuario.
WS-Security Policy.- Es una especificación para servicios web basada o derivada de WS-Policy,
proporciona una forma más simple de configurar limitaciones o requerimientos de seguridad de los servicios web definidos en el documento WSDL. Permite especificar ciertos tipos de afirmaciones (Sosnoski, 2011):
Nav egador Prov eedor del
Serv icio Prov eedor de Identidad 1 2 3 4 5 6 7 Get Recurso Redirecciona al Id Proveedor
Get SAML petición de autenticación
Autenticación de usuario
Página HTML petición de autenticación
Post SAML respuesta de autenticación Recurso
61
• Security binding assertions: <sp:TransportBinding>, <sp:SymmetricBinding> and
<sp:AsymmetricBinding>.
• Supporting token assertions: <sp:SupportingTokens> and
<sp:SignedSupportingTokens>.
• Option assertions: <sp:Wss10>, <sp:Wss11>, <sp:Trust13>. • Protection: <sp:RequiredParts>.
WS-Security usa una estructura compleja y confusa para implementarla manualmente, por tal razón la mayoría de los framework para servicios web integran una interfaz dinámicas para la creación de estos documentos; por ejemplo Metro es una herramienta que a través de WSIT facilita esta difícil tarea. La intención de WS-Security Policy es proporcionar la suficiente información para la compatibilidad e interoperabilidad para el intercambio seguro de mensajes.
Como propuesta para el desarrollo del prototipo en la Figura 23, se propone el siguiente esquema general de seguridad para la construcción del servicio web:
Figura 23. Estándares de seguridad implementados en servicios SOAP
Fuente: Autor Elaboración: Autor Calidad Descripción Mensaj ería Transporte Core XML WS-Security SAML WS-SecurityPolicy Ecriptación Firma Digital
WSDL
SOAP
HTTPS
62
En la Tabla 7, se resume los patrones de diseño, protocolos, estándares de seguridad y herramientas de desarrollo para el prototipo propuesto, así como una breve descripción de los mismos.
Tabla 7. Resumen de tecnologías utilizadas
COMPONENTE NOMBRE DESCRIPCIÓN
Patrones
Facade
Estructurar la codificación y ocultar la lógica de negocio de la aplicación para el cliente. Además que permite la reutilización y la fácil modificación en el código al momento de realizar cambios.
DAO
Gestionar la persistencia de los datos. Es la encargada de interacción con la base de datos, es decir controla el acceso a la base de datos actuando de intermediario entre la base de datos y la aplicación.
Lenguaje de
Programación Java 1.7
Lenguaje de programación multiplataforma ideal para aplicaciones empresariales mediante JavaEE. Además provee un aserie de API´s que facilitan de implementación de aplicaciones web.
Base de Datos MySQL 5.0
Motor de base de datos gratuito, flexible, escalable y multiplataforma, permite la creación de procedimientos almacenados y permite gestionar privilegios de usuarios para evitar ataques SQL Injection.
Servidor de
Aplicaciones Glassfish 4.1
Servidor de aplicaciones que soporta JavaEE, además permite la implementación de servicios web SOAP mediante su api JAX-WS.
Framework
Metro 2.3
Framework para la implementación de servicios web SOAP, contiene una pila de tecnologías y proyectos como JAX-WS y WSIT que permiten la interoperabilidad y la implementación de servicios web seguros.
Estándares de
Seguridad WS-Security 1.0
Estándar para implementar seguridad a servicios web SOAP, provee un modelo unificado de cómo utilizar mecanismo de seguridad para autenticación, confidencialidad e integridad de los datos de los servicios web
63 SAML 2.0
Especificación basada en XML para el intercambio de información mediante la autenticación, asegurado la integridad y confidencialidad de los datos, mediante aserciones integradas a través del estándar WS-Security Policy.
WS-Security Policy 1.2
Afirmaciones de políticas de seguridad basadas en el marco WS-Policy, donde se definen las políticas, las limitaciones y requerimientos de seguridad en el documento WSDL del servicio web.
Transporte HTTPS / SSL
Protocolo de seguridad a nivel de transporte para aplicaciones web, utiliza el cifrado basado en SSL creando un canal seguro por el cual transitan los datos.
Fuente: Autor Elaboración: Autor
64
CAPÍTULO III
65
En el presente capítulo se expone el diseño de un servicio web SOAP, el cual permite que los mensajes XML pueden transportarse por diversos protocolos de transporte, pero en éste caso utilizaremos HTTP ya que es el protocolo más utilizado; al utilizar HTTP significa que cada mensaje debe pasar por varios nodos, pudiendo éstos nodos modificar el contenido de los mensajes afectando así la confidencialidad de los datos; es decir que a diferencia de servicios web basados en REST que solo soportan HTTPS, los servicios web SOAP soporta las especificaciones de WS- Security, asegurando la comunicación de origen a destino y no solo de punto a punto. Comparación que se menciona por Navarro Marset (2006),entre otras más.
Con la finalidad de que la aplicación web contenga una seguridad adecuada que implique autenticación, autorización de los servicios web, la encriptación de los datos sensibles y la prevención de ataques de SQL injection y ataques XSS, se implementará diferentes métodos, estándares y especificaciones como: WS-Security, SSL descritas en capítulos anteriores.