You are on page 1of 134

UNIVERSIDAD TCNICA PARTICULAR DE LOJA

La Universidad Catlica de Loja

REA TCNICA
TTULO DE INGENIERO EN SISTEMAS INFORMTICOS Y
COMPUTACIN

Consideraciones de Arquitectura de Software a nivel de Diseo Arquitectnico


y Desarrollo de Software para minimizar vulnerabilidades en aplicaciones web
basados en OWASP Top Ten 2013, caso de estudio arquitectura: SOA.

TRABAJO DE TITULACIN

AUTOR: Tenezaca Lima, Miguel Alejandro


DIRECTOR: Guamn Coronel, Daniel Alejandro, Mgs.

LOJA ECUADOR
2016

Esta versin digital, ha sido acreditada bajo la licencia Creative Commons 4.0, CC BY-NYSA: Reconocimiento-No comercial-Compartir igual; la cual permite copiar, distribuir y
comunicar pblicamente la obra, mientras se reconozca la autora original, no se utilice con
fines comerciales y se permiten obras derivadas, siempre que mantenga la misma licencia al
ser divulgada. http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es
Septiembre, 2016

APROBACIN DEL DIRECTOR DEL TRABAJO DE TITULACIN

Magister
Daniel Alejandro Guamn Coronel
DOCENTE DE LA TITULACIN

De mi consideracin:
El presente trabajo de titulacin: Consideraciones de Arquitectura de Software a nivel de Diseo
Arquitectnico y Desarrollo de Software para minimizar vulnerabilidades en aplicaciones web
basados en OWASP Top Ten 2013, caso de estudio arquitectura: SOA, realizado por Miguel
Alejandro Tenezaca Lima, ha sido orientado y revisado durante su ejecucin, por cuanto se
aprueba la presentacin del mismo

Loja, marzo de 2016

f). ............................
Mgs. Daniel Alejandro Guamn Coronel
CI: 1103777403

ii

DECLARACIN DE AUTORA Y CESIN DE DERECHOS


Yo Miguel Alejandro Tenezaca Lima declaro ser autor (a) del presente trabajo de titulacin:
Consideraciones de Arquitectura de Software a nivel de Diseo Arquitectnico y Desarrollo de
Software para minimizar vulnerabilidades en aplicaciones web basados en OWASP Top Ten 2013,
caso de estudio arquitectura: SOA, de la Titulacin de Sistemas Informticos y Computacin,
siendo el Ing. Daniel Alejandro Guamn director (a) del presente trabajo; y eximo expresamente a
la Universidad Tcnica Particular de Loja y a sus representantes legales de posibles reclamos o
acciones legales. Adems certifico que las ideas, conceptos, procedimientos y resultados vertidos
en el presente trabajo investigativo, son de mi exclusiva responsabilidad.
Adicionalmente declaro conocer y aceptar la disposicin del Art. 88 del Estatuto Orgnico de la
Universidad Tcnica Particular de Loja que en su parte pertinente textualmente dice: Forman parte
del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos cientficos o
tcnicos y tesis de grado o trabajos de titulacin que se realicen con el apoyo financiero, acadmico
o institucional (operativo) de la Universidad

f). ............................
Autor: Miguel Alejandro Tenezaca Lima
Cdula: 0705705721

iii

DEDICATORIA

Mi trabajo de fin de titulacin lo dedico con cario:


A Dios, que me dio la oportunidad de vivir y el maravilloso regalo de mi familia.
A mis padres, que me han apoyado firmemente y han depositado toda su confianza en m,
brindndome sus sabias enseanzas y gracias a ellos he podido culminar mis estudios
profesionales.
A mis hermanos, que han sido una de mis motivaciones para mi superacin personal y profesional.
A mis familiares, amigos y compaeros, que siempre han estado pendientes de bienestar.

iv

AGRADECIMIENTO

Un cordial y respetuoso agradecimiento por la culminacin del presente trabajo de fin de titulacin:
A Dios por la vida y las bendiciones que me ha dado.
A mis padres por su apoyo incondicional.
A mi director de Trabajo de fin de titulacin por su apoyo y orientacin durante la elaboracin de
este trabajo.
A mi comit del tribunal por sus correcciones y aportaciones en el presente trabajo

CONTENIDO

CONTENIDO ................................................................................................................................... vi
NDICE DE FIGURAS ...................................................................................................................... x
NDICE DE TABLAS ..................................................................................................................... xiii
RESUMEN .......................................................................................................................................1
ABSTRACT ......................................................................................................................................2
INTRODUCCIN .............................................................................................................................3
Delimitacin y definicin del problema ......................................................................................... 4
Objetivos....................................................................................................................................... 5
Objetivo General ...................................................................................................................... 5
Objetivos Especficos ............................................................................................................... 5
GLOSARIO DE TRMINOS ............................................................................................................6
CAPTULO I......................................................................................................................................8
ESTADO DEL ARTE ........................................................................................................................8
1.1.

Arquitectura de Software. .................................................................................................. 9

1.1.1.

Definicin. .................................................................................................................. 9

1.1.2.

Caractersticas de la Arquitectura de software. ....................................................... 10

1.1.3.

Ventajas y desventajas del uso de Arquitecturas de software ................................ 10

1.1.4.

Ciclo de desarrollo de la Arquitectura de Software. ................................................ 11

1.2.

Estilos Arquitectnicos .................................................................................................... 12

1.2.1.

Definicin ................................................................................................................. 12

1.2.2.

Tipos de estilos arquitectnicos............................................................................... 12

1.3.

Patrones .......................................................................................................................... 16

1.3.1.

Patrones Arquitectnicos......................................................................................... 16

1.3.2.

Patrones de Diseo. ................................................................................................ 20

1.4.

Servicios web. ................................................................................................................. 27

vi

1.4.1.

Definicin ................................................................................................................. 27

1.4.2.

Estructura y caractersticas de los Servicios Web................................................... 28

1.4.3.

Especificaciones de los servicios web..................................................................... 29

1.4.4.

Ventajas y desventajas de los Servicios Web ......................................................... 31

1.5.

Arquitectura Orientada a Servicios. ................................................................................ 32

1.5.1.

Definicin ................................................................................................................. 32

1.5.2.

Principios de la Orientacin a Servicios. ................................................................. 33

1.5.3.

Caractersticas de un servicio web SOA ................................................................. 35

1.5.4.

Ventajas y desventajas de SOA ............................................................................. 36

1.5.5.

Elementos de SOA. ................................................................................................. 38

1.5.6.

Capas de la arquitectura SOA. ................................................................................ 39

1.5.7.

Funcionamiento de SOA. ........................................................................................ 40

1.6.

Vulnerabilidades .............................................................................................................. 41

1.6.1.

Definicin ................................................................................................................. 41

1.6.2.

Tipos de vulnerabilidades ........................................................................................ 42

1.7.

OWASP (The Open Web Application Security Project).................................................. 44

1.7.1.

Definicin ................................................................................................................. 44

1.7.2.

OWASP Top Ten..................................................................................................... 45

CAPTULO II...................................................................................................................................50
PROPUESTA DE SOLUCIN .......................................................................................................50
2.1.

Identificacin de vulnerabilidades ................................................................................... 51

2.2.

Patrn arquitectnico ...................................................................................................... 52

2.3.

Patrones de diseo ......................................................................................................... 52

2.4.

Herramientas para el desarrollo del prototipo ................................................................. 53

2.5.

Identificacin de protocolos y estndares de seguridad ................................................. 56

CAPTULO III..................................................................................................................................64
DISEO DE LA SOLUCIN ..........................................................................................................64

vii

3.1

Diseo Arquitectnico de la aplicacin ........................................................................... 65

3.1.1. Web Service ................................................................................................................. 66


3.1.2. Client App ..................................................................................................................... 67
3.2. Diseo de base de datos..................................................................................................... 67
3.3. Diseo de Seguridad ........................................................................................................... 67
3.3.1. Codificacin .................................................................................................................. 67
3.3.2. Configuracin ............................................................................................................... 68
3.3.3. Base de datos .............................................................................................................. 70
CAPTULO IV .................................................................................................................................71
IMPLEMENTACIN DE LA SOLUCIN .......................................................................................71
4.1.

Base de datos ................................................................................................................. 72

4.2. Codificacin ...................................................................................................................... 73


4.3. Seguridad .......................................................................................................................... 79
4.3.1. Servicio Web .............................................................................................................. 79
4.3.2. Aplicacin Cliente Servicio Web ................................................................................. 84
4.3.3. Filtros de Seguridad .................................................................................................... 84
CAPTULO V ..................................................................................................................................88
VALIDACIN..................................................................................................................................88
5.1.

Validacin de Diseo....................................................................................................... 89

5.2.

Validacin de Cdigo ...................................................................................................... 90

5.2.1. Primera Iteracin ........................................................................................................ 91


5.2.2. Segunda Iteracin ...................................................................................................... 93
5.3.

Validacin de Seguridad ................................................................................................. 94

5.3.1. Validacin con Herramientas ..................................................................................... 94


5.3.2. Validacin Manual ...................................................................................................... 99
CONCLUSIONES ....................................................................................................................... 104
RECOMENDACIONES ............................................................................................................... 105

viii

BIBLIOGRAFA ........................................................................................................................... 106


ANEXOS...................................................................................................................................... 110
A. Modelo Entidad-Relacin de base de datos. .................................................................... 111
B. Procedimientos almacenados implementados. ................................................................ 112
C.

Documento WSDL del servicio web PftWebService implementado sin seguridad. ..... 113

D.

Configuracin SAML con WSIT Servicio web............................................................ 115

E. Configuracin SAML con WSIT Cliente del Servicio web. ............................................ 119

ix

NDICE DE FIGURAS

Figura 1. Arquitectura Centrada en Datos..................................................................................... 13


Figura 2. Arquitectura Flujo de Datos ............................................................................................ 13
Figura 3. Arquitectura Llamada y Retorno .................................................................................... 14
Figura 4. Arquitectura Orientada a Objetos................................................................................... 14
Figura 5. Arquitectura Orientada a Servicios................................................................................. 15
Figura 6. Relacin de abstraccin entre estilos y patrones arquitectnicos ................................. 26
Figura 7. Especificaciones de los servicios web .......................................................................... 30
Figura 8. Integracin SOA ............................................................................................................. 33
Figura 9. Interrelacin entre los Principios SOA............................................................................ 35
Figura 10. Elementos de SOA....................................................................................................... 38
Figura 11. Capas de SOA. ............................................................................................................ 39
Figura 12. Ciclo de funcionamiento de los servicios web SOA..................................................... 40
Figura 13. SQL Injection ................................................................................................................ 46
Figura 14. Ejemplo de sentencia SQL........................................................................................... 46
Figura 15. Ejemplo de SQL Injection............................................................................................. 47
Figura 16. Secuencia de comandos en sitios cruzados................................................................ 48
Figura 17. Exposicin de datos sensibles. .................................................................................... 49
Figura 18. Componentes WSIT..................................................................................................... 55
Figura 19. Ejemplo de SOAP Request y SOAP Response .......................................................... 57
Figura 20. Estructura de documento WSDL ................................................................................. 58
Figura 21. Flujo de mensajes mediante WS-Security ................................................................... 59

Figura 22. Autenticacin SAML ..................................................................................................... 60


Figura 23. Estndares de seguridad implementados en servicios SOAP .................................... 61
Figura 24. Diseo arquitectnico de aplicacin SOA propuesta................................................... 66
Figura 25. Creacin de Procedimientos Almacenados en MySQL............................................... 72
Figura 26. Procedimientos Almacenados ..................................................................................... 73
Figura 27. Dependencias - Archivo POM.xml ............................................................................... 74
Figura 28. Diagrama de paquetes del proyecto pft-ws ................................................................. 75
Figura 29. Archivo glassfish-resources.xml................................................................................... 76
Figura 30. Paquete DAO ............................................................................................................... 76
Figura 31. Clase PftPersonaService - Paquete Service ............................................................... 77
Figura 32. Operacin getPersonas PftWebService ................................................................... 78
Figura 33. Operacin getModalidades PftWebService .............................................................. 78
Figura 34. Operacin personaPorCedula PftWebService ......................................................... 79
Figura 35. Clase FiltroSecurity ...................................................................................................... 84
Figura 36. Configuracin de filtros de seguridad - web.xml .......................................................... 85
Figura 37. Clase XSSRequestWrapper ........................................................................................ 86
Figura 38. Cdigo para encriptar DES ....................................................................................... 87
Figura 39. Diseo arquitectnico Validacin .............................................................................. 89
Figura 40. Patrn de Diseo Facade Validacin........................................................................ 90
Figura 41. Estabilidad del prototipo - Validacin ........................................................................... 90
Figura 42. Primera Iteracin SonarQube ...................................................................................... 91
Figura 43. Segunda Iteracin SonarQube .................................................................................... 93
Figura 44. Captura del trfico con HTTP - Wireshark ................................................................... 96

xi

Figura 45. Captura del trfico con HTTPS - Wireshark................................................................. 98


Figura 46. Cliente sin autenticacin SAML ................................................................................... 98
Figura 47. Captura de errores de autenticacin SAML ................................................................. 99
Figura 48. Consulta de personas por cdula ................................................................................ 99
Figura 49. Ataque SQL Injection ................................................................................................. 100
Figura 50. Cdigo incorrecto de consulta SQL ........................................................................... 100
Figura 51. Cdigo correcto de consulta SQL .............................................................................. 101
Figura 52. Aplicacin Web contra ataque SLQ Injection............................................................. 101
Figura 53. Insertar cdigo JavaScript en la base de datos ......................................................... 102
Figura 54. Resultado de la Insercin de script en la base de datos ........................................... 102
Figura 55. Ataque XSS................................................................................................................ 103
Figura 56. Modelo Entidad Relacin de la base de datos........................................................... 111
Figura 57. Editar Atributos del Servicio Web Configuracin .................................................... 115
Figura 58. Seleccin del mecanismos de seguridad - Configuracin WSIT ............................... 116
Figura 59. Configuracin Keystore .............................................................................................. 117
Figura 60. Configuracin Truststore ............................................................................................ 117
Figura 61. Encriptacin y Firmado de mensajes SOAP.............................................................. 118
Figura 62. Importacin del WSDL en el cliente ........................................................................... 119
Figura 63. Editar atributos del servicio web cliente ..................................................................... 119
Figura 64. Configuracin Keystore Cliente............................................................................... 120
Figura 65. Configuracin Truststore Cliente............................................................................. 120
Figura 66. Configuracin SamlCallbackHandler Cliente .......................................................... 120

xii

NDICE DE TABLAS

Tabla 1. Patrones arquitectnicos .................................................................................................. 18


Tabla 2. Patrones de diseo........................................................................................................... 22
Tabla 3. Diferencias entre estilos arquitectnicos y patrones arquitectnicos............................... 26
Tabla 4. Ventajas y desventajas de los servicios web ................................................................... 31
Tabla 5. Ventajas y desventajas de la Arquitectura Orientada a Servicios ................................... 37
Tabla 6. Mitos y realidades sobre SOA. ......................................................................................... 41
Tabla 7. Resumen de tecnologas utilizadas.................................................................................. 62
Tabla 8. Requerimientos para configuracin de SAML Authorization Vouches with Certificates.. 69
Tabla 9. Apis de java utilizadas en el proyecto .............................................................................. 73
Tabla 10. Prueba de cdigo con SonarQube - Iteracin 1............................................................. 92
Tabla 11. Alertas del prototipo sin seguridad ................................................................................. 95
Tabla 12. Alertas del prototipo con seguridad ................................................................................ 96
Tabla 13. Procedimientos almacenados utilizados ...................................................................... 112

xiii

RESUMEN
La orientacin a servicios permite la integracin y automatizacin de procesos de las empresas los
mismos que al estar disponibles en la web son vulnerables a sufrir algn tipo de ataque; por ende
existen organizaciones como OWASP encargadas de concientizar a los desarrolladores en la
creacin de software seguro y de calidad mediante el uso de normas y recomendaciones para
evitar vulnerabilidades. El presente trabajo se centr en la implementacin de un prototipo para
mitigar vulnerabilidades de tipo: SQL Injection, XSS y exposicin de datos sensibles en
aplicaciones web construidas bajo el estilo arquitectnico SOA utilizando el patrn arquitectnico
MVC, patrones de diseo Facade y DAO, tcnicas de seguridad OWASP a nivel de codificacin y
configuracin en el lenguaje de programacin Java EE en Glassfish y la especificacin WSSecurity.
Finalmente el prototipo fu validado con herramientas como: Structural Analysis for Java,
SonarQube, OWASP ZAP, Vega y Wireshark, para comprobar la calidad del prototipo a nivel de
diseo, de codificacin y de seguridad para contrarrestar los tipos de vulnerabilidades.
Palabras Clave: Exposicin de datos sensibles, Inyeccin SQL, OWASP, SOA, SOAP, WSSecurity, XSS.

ABSTRACT
Services orientation allow the integration and automating process of business the same as being
available on the network are vulnerable to suffer any type of attack, there are some organization as
OWASP responsable of raising awareness to the developers in the creation of a secure software
and the quality through the use of standards and recommendations to avoid vulnerabilities. The
present work was focus on the implementation of a prototype to reduce vulnerabilities such as: SQL
Injection, XSS and exposure of sensitive data in web applications built under SOA using MVC as
architectural pattern, Facade and DAO as design patterns, and principles and best practices given
by OWASP to writing secure code, through Java EE configure the Glassfish Server and WSSecurity specification.
Finally, the prototype was validate with tools such as: Structural Analysis for Java, SonarQube,
OWASP, Vega and Wireshark, to analyze the quality of the prototype in terms of coding, design
and security to counteract the vulnerability types.
Key words: Exposure of sensitive data, OWASP, SOA, SOAP, SQL Injection, WS-Security, XSS.

INTRODUCCIN
Internet ofrece el ambiente ideal para la creacin de aplicaciones web que permiten el intercambio
de informacin, transacciones electrnicas entre otras funcionalidades, sobre todo permitiendo la
interaccin entre las empresas y sus clientes. La Arquitectura Orientada a Servicios (SOA) permite
integrar diversos tipos de aplicativos mediante los servicios web, los cuales deben cumplir ciertos
requisitos del cliente y adems poseer ciertos estndares de seguridad que garanticen que la
aplicacin final sea de calidad.
Bajo este criterio en el presente proyecto se propone que a travs del uso del patrn arquitectnico
MVC y de los patrones de diseo Facade y DAO se minimicen las vulnerabilidades a nivel de
desarrollo de cdigo de dichas aplicaciones, para ello se realiza un anlisis y estudio de algunas
metodologas, tcnicas y procedimientos que asociadas a dicha arquitectura permitan cumplir con
el objetivo desde el punto de vista de diseo y desarrollo de software.
Para el desarrollo del proyecto se han propuesto las siguientes actividades para su cumplimiento:

Contextualizacin del estado de arte para el desarrollo del producto software.

Diseo de la solucin/prototipo software.

Desarrollo de la solucin/prototipo Software.

Validacin de la solucin/prototipo software

La finalidad del presente proyecto es utilizar la gua de OWASP para elaborar un prototipo bajo el
estilo arquitectnico SOA, en el cual se expongan las consideraciones de cdigo y diseo que
permitan minimizar vulnerabilidades en aplicaciones web.

Delimitacin y definicin del problema


En la actualidad SOA ha adquirido una gran importancia debido a que permite la flexibilidad y la
integracin de aplicativos desarrollados en diferentes plataformas, realizar transacciones e
intercambiar informacin, lo que ha permitido generar nuevas oportunidades y problemas. El
software inseguro amenaza de forma permanente y directa a las aplicaciones o servicios expuestos
en la web, lo que hace que los sistemas sean vulnerables, poniendo en riesgo la informacin que
se maneja en stos. Por tal razn el presente proyecto busca obtener una gua con las normas y
estndares de seguridad que se adapte al diseo y desarrollo de aplicaciones web con el estilo
arquitectnico SOA.
OWASP es una fundacin sin fines de lucro que busca combatir los diferentes riesgos que se
asocian a las aplicaciones web; en sta investigacin se considera que en funcin de los tipos de
vulnerabilidades expuestos en el Top Ten 2013 de OWASP debe analizarse los tipos de
vulnerabilidades a considerar cuando se trabajan con el estilo arquitectnico SOA. Uno de los
objetivos principales de OWASP es crear conciencia en los desarrolladores para escribir un buen
cdigo con la finalidad de incrementar la seguridad en las aplicaciones web.
El presente trabajo tiene como propsito investigar, analizar y poner en prctica algunas
consideraciones a nivel de diseo arquitectnico y desarrollo de software para la elaboracin de
aplicaciones web seguras con el fin de minimizar ciertos tipos de vulnerabilidades que pueden
incidir al utilizar un estilo arquitectnico SOA.
Finalmente para la parte prctica se ha considerado desarrollar un prototipo base acorde al estilo
arquitectnico SOA, en donde se muestre: el diseo arquitectnico, el patrn arquitectnico, los
patrones de diseo seleccionados y consideraciones a nivel de escritura de cdigo, que luego
sern validados con herramientas y de forma manual.

Objetivos
Objetivo General
Identificar los patrones, mtricas y estndares que asociados al estilo arquitectnico SOA permitan
minimizar algunos de los tipos de vulnerabilidades listados en OWASP Top Ten 2013 desde el
punto de vista de diseo arquitectnico y desarrollo de software.

Objetivos Especficos

Analizar los tipos de vulnerabilidades que pueden afectar la seguridad de una aplicacin
de software diseada bajo un estilo arquitectnico SOA.

Identificar los patrones de diseo, patrones arquitectnicos, patrones de seguridad o


frameworks que permitan y garanticen un diseo arquitectnico adecuado y una
codificacin de software segura para aplicarlo en una arquitectura orientada a servicios.

Disear e implementar un prototipo de software utilizando patrones, mtricas, estndares


a nivel de diseo arquitectnico y codificacin recomendados por la gua de OWASP para
minimizar aspectos de seguridad cuando se trabaja con SOA.

GLOSARIO DE TRMINOS
API.- Aplication Programming Interface (Interfaz de Programacin de Aplicaciones).
CORBA.- Common Object Request Broker Architecture (Arquitectura comn de intermediarios en
peticiones a objetos).
DAO.- Data Access Object (Objeto de Acceso a Datos).
DCOM.- Distributed Component Object Model (Modelo de Objetos de Componentes Distribuidos).
EJB.- Enterprise JavaBeans (Beans empresariales de Java).
HTTP.- Hypertext Transfer Protocol (Protocolo de Transferencia de Hipertexto).
HTTPS.- Hypertext Transfer Protocol Secure (Protocolo de Transferencia de Hipertexto Seguro).
IDE.- Integrated Development Enviromment (Ambiente de Desarrollo Integrado).
J2EE.- Java 2 Platform Enterprise Edition (Edicin Empresarial de la Plataforma Java 2).
JPA.- Java Persistence Api (Api de Persistencia de Java).
JSF.- Java Server Faces.
JSP.- JavaServer Pages.
MVC.- Model View Controller (Modelo Vista Controlador).
ORM.- Object-Relational Mapping (Mapeo Objeto-Relacional)
OWASP.- The Open Web Application Security Project.
OWASP ZAP.- OWASP Zed Attack Proxy.
RPC.- Remote Procedure Call (Llamadas a Procedimientos Remotos).
SMTP.- Simple Mail Transfer Protocol (Protocolo para Transferencia Simple de Correo).
SOA.- Service Oriented Architecture (Arquitectura Orientada a Servicios).
SOAP.- Simple Object Access Protocol (Protocolo Simple de Acceso a Datos).
SQL.- Estrutured Query Languaje (Lenguaje de Consulta Estructurado).

SSL.- Secure Sockets Layer.


TOKEN.- Un token de seguridad (tambin token de autenticacin o token criptogrfico).
UDDI.- Universal Description, Discovery and Integration.
URI.- Uniform Resource Identiflier
W3C.- World Wide Web Consortium.
WS-BPEL.- Web Service Business Process Execution Language (Lenguaje de Ejecucin de
Procesos de Negocio con Servicios Web).
WS-CDL.- Web Services Choreography Description Language (Lenguaje para la descripcin de
Coreografas de Servicios Web).
WSDL.- Web Services Description Language (Lenguaje de Descripcipon de Servicios Web).
WS-I.- Web Service Interoperability.
WSIT.- Web Service Interoperability Technologies.
XML.- eXtensible Markup Language (Lenguaje de Marcas extensible).
XSS.- Cross Site Scripting (Secuencias de comandos en Sitios Cruzados).

CAPTULO I

ESTADO DEL ARTE

1.1. Arquitectura de Software.


1.1.1.

Definicin.

Cervantes (2010) se refiere a la arquitectura de software como la estructuracin del sistema


elaborado en etapas iniciales del desarrollo del software, la misma que representa un diseo de
alto nivel con el objetivo de satisfacer los atributos de calidad y servir como de gua de referencia
para los desarrolladores.
Para L. F. Fernndez (2006) la arquitectura de software ha emergido como una disciplina de gran
importancia dentro de la ingeniera de software. Una arquitectura adecuada es pieza clave para
lograr tanto requerimientos funcionales como no funcionales de un sistema. Por otro lado una
arquitectura no adecuada puede ser catastrfica.
La arquitectura de software se puede definir como la estructura o estructuras del sistema, que
comprenden componentes de software, las propiedades externamente visibles de esos
componentes, y las relaciones entre ellos (Gardazi & Shahid, 2009).

Y Bosch (2000),

complementa el concepto de arquitectura de software mencionando que la arquitectura de


software es importante porque afecta el desempeo, la potencia, la capacidad de distribucin y el
mantenimiento de un sistema.
La arquitectura de software identifica los diferentes componentes del sistema, la interaccin entre
ellos y la configuracin del sistema, la arquitectura de software se puede documentar de manera
adecuada mediante el uso de diagramas simples donde se indican los componentes o elementos
del sistema y la interaccin entre ellos. La tcnica de la arquitectura es la descomposicin del
sistema en componentes ms pequeos con aspectos especficos comunes, mediante la
abstraccin, y que al unirse y organizarse permiten la solucin de un problema especfico ms
grande. En la arquitectura de software se contemplan las propiedades de un sistema en su entorno
formada por sus elementos, relaciones y por los principios de su diseo y evolucin.
Como lo menciona Bosch (2000), la arquitectura de un sistema depende de los requerimientos no
funcionales como: Rendimiento, Seguridad, Proteccin, Disponibilidad y Mantenibilidad.

Rendimiento.- Se refiere a las respuestas del sistema, ya sea el tiempo requerido para
responder a eventos especficos o a la cantidad de eventos procesados en un intervalo
de tiempo dado. La arquitectura debe disearse para localizar operaciones crticas de
un pequeo nmero de componentes desplegados en la misma computadora.

Seguridad.- Se debe usar una estructura en capas para proteger los componentes ms
vulnerables en las capas ms internas, con un alto nivel de seguridad aplicado en dichas
capas.

Proteccin.- La arquitectura se debe disear de modo que las operaciones


relacionadas con la proteccin se ubiquen en algn componente individual. Con esto se
reduce los costes y los problemas de validacin de la proteccin.

Disponibilidad.- La arquitectura tiene que disearse para incluir componentes


redundantes de manera que sea posible sustituir y actualizar los componentes sin
detener el sistema

Mantenibilidad.- La arquitectura debe disearse usando componentes auto contenidos


que puedan cambiarse con facilidad, conservando su funcionamiento normal.

1.1.2.

Caractersticas de la Arquitectura de software.

Una buena arquitectura de software debe poseer las siguientes caractersticas:

Facilidad para los usuarios y desarrolladores en la comprensin del sistema.

La planificacin de proyectos, el anlisis de riesgo, la organizacin, el proceso de


desarrollo, los ciclos de trabajo, el hardware, la garanta de calidad y los requerimientos
son factores influyentes de la arquitectura de software

Es una representacin abstracta de alto nivel de la estructura del sistema describiendo


las partes que lo integran.

Contiene patrones que controlan la composicin y las restricciones del sistema.

Implica aspectos de diseo y desarrollo de software.

Se compone de los componentes, las propiedades y las relaciones que se establecen


entre ellos.

Es la base de la construccin del software.

Se concentra en los requerimientos no funcionales del sistema.

1.1.3.

Ventajas y desventajas del uso de Arquitecturas de software

La arquitectura de software es un elemento base e importante para el desarrollo; y ha surgido como


una disciplina de gran importancia dentro de la ingeniera de software. Una arquitectura adecuada
es pieza clave para lograr tanto los requerimientos funcionales como no funcionales de un sistema.
Como principales ventajas de la arquitectura de software se puede mencionar: permite la toma de
decisiones tempranas antes de elaborar el diseo, permite la comunicacin entre los integrantes

10

del equipo de desarrollo, sirve como puente entre los requerimientos del sistema y la
implementacin, permite la reutilizacin y permite predecir y mitigar riesgos ofreciendo un software
de calidad (C. Reynoso, 2004). Por otro lado, una arquitectura no adecuada puede ser catastrfica,
Clements & Northrop (1996) nombra algunos aspectos negativos de la arquitectura de software:
no existe un criterio unificado acerca de la arquitectura de software, limitaciones tecnolgicas y el
tiempo de elaboracin del marco de referencia es bastante amplio.
1.1.4.

Ciclo de desarrollo de la Arquitectura de Software.

Cervantes (2010) menciona que el ciclo de desarrollo de la arquitectura de un software es


independiente de la metodologa que se utilice en el proyecto de desarrollo de software, y se
compone de las siguientes etapas: Requerimientos, Diseo, Documentacin y Evaluacin. As
mismo Barraza ( n.d.) define las etapas del proceso de desarrollo de arquitectura de software en 3
etapas: Definicin de requerimientos, Diseo de la arquitectura y Validacin. A continuacin se
resumen en que consiste cada etapa:

Definicin de requerimientos.- Esta etapa se centra en la recopilacin,


documentacin y priorizacin de los requisitos o requerimientos que afecten a la
arquitectura; estos requerimientos principalmente son los atributos de calidad del
sistema. Tambin los requisitos funcionales afectan a la arquitectura y se las toma en
cuenta en esta fase as como las restricciones.

Diseo de la arquitectura.- Esta etapa es la ms complicada, porque es aqu donde


se definen las estructuras y responsabilidades de los componentes de la arquitectura,
en base a patrones de diseos, tcnicas de diseo y la seleccin de herramientas
tecnolgicas para el diseo arquitectnico; el diseo debe satisfacer los requerimientos
identificados en la fase anterior.

Documentacin.- Al diseo arquitectnico anterior se lo debe documentar de forma


apropiada, ya que de esta depende que los dems interesados en el desarrollo la
puedan entender. La documentacin de la arquitectura se compone de la
representacin de las estructuras a travs de distintas vistas. Las vistas por lo general
estn conformadas por diagramas con informacin adicional que apoya la compresin
del diagrama.

Evaluacin o validacin.- Se prueba o verifica el diseo con los requerimientos


actuales y posibles nuevos requerimientos. Se lo puede hacer de forma manual o
mediante prototipo. El diseo arquitectnico es la base para la codificacin, por ende
sta se debe evaluar para identificar, corregir posibles errores y riesgos, y permitir que
11

el equipo de desarrollo implemente los componentes, conectores y configuracin


adecuada.
En base a lo expuesto anteriormente la base para la construccin de una buena arquitectura de
software es la identificacin de los requisitos que se deben resolver con el sistema, luego el diseo
de una arquitectura en base a los requerimientos y finalmente la validacin de la arquitectura
diseada. Sin dejar de lado que todo esto debe estar bien documentado para posibilitar la
comunicacin entre los interesados, y poder llevar un mejor monitoreo sobre el ciclo de desarrollo
de la arquitectura de software.
1.2. Estilos Arquitectnicos
1.2.1.

Definicin

Segn Camacho, Cardeso, & Nuez (2004) define al estilo arquitectnico como un patrn que
organiza estructuralmente los componentes, tipos de conectores y un conjunto de limitaciones o
restricciones de cmo pueden ser usadas.
Buschmann, Meunie, Rohnert, Sommerlad, & Stal (2000) considera los estilos arquitectnicos
como la base fundamental de la estructura de un sistema software, asociado de mtodos que
especifican la forma de implementarlo, cuando usarlo, sus especializaciones y las consecuencias
de sus uso.
1.2.2.

Tipos de estilos arquitectnicos

Los estilos arquitectnicos indican los tipos de componentes y conectores involucrados. A


continuacin se detallan algunos tipos de estilos arquitectnicos (Rivera Posso, 2004):

Arquitecturas Centradas en Datos: Esta arquitectura sita en el centro un almacn de


datos que puede ser un documento o una base de datos, al que otros componentes pueden
acceder para actualizar, agregar o eliminar datos a dicho almacn. Existen dos tipos de
repositorios: Pasivo y Activo (pizarra). Como ventajas de este estilo arquitectnico brinda
integridad, es decir si existen cambios en los componentes, estos no afectan a los otros
componentes. Como se muestra en la Figura 1:

12

Fuente de
Conocimiento

Fuente de
Conocimiento

Fuente de
Conocimiento

Base de Datos

Fuente de
Conocimiento

Figura 1. Arquitectura Centrada en Datos


Fuente: (C. B. Reynoso, 2004)
Elaboracin: Autor

Arquitecturas de Flujo de Datos: En esta arquitectura los datos de entrada son


transformados a travs de una serie de componentes en datos de salida. Est constituido
por Filtros conectados por Tuberas que se encargan de transmitir los datos entre los
componentes. Los filtros estn diseados para recibir los datos de entrada de una forma y
producir la salida de otra forma. Como se muestra es la Figura 2:
Tubera

Tubera
Filtro

Tubera
Filtro

Filtro

Tubera

Tubera
Filtro

Filtro

Tubera
Filtro

Figura 2. Arquitectura Flujo de Datos


Fuente: (C. B. Reynoso, 2004)
Elaboracin: Autor

Arquitecturas de Llamada y Retorno: Provee de estructuras de programas de fcil


cambio y escalabilidad. Es muy utilizado en sistemas de gran escala, y este estilo se divide
en sub estilos: programa principal/subprograma, llamada de procedimiento remoto. Como
se muestra en la Figura 3:

13

Programa
Principal

Rutina 1

Rutina 1.1

Rutina 2

Rutina 1.2

Rutina 3

Rutina 3.1

Rutina 3.2

Figura 3. Arquitectura Llamada y Retorno


Fuente: (Sommerville, 2011)
Elaboracin: Autor

Arquitectura Orientada a Objetos: Los datos y operaciones se encapsulan en los


componentes del sistema, para luego ser utilizados. La comunicacin y coordinacin entre
los componentes es realizado por medio de envo de mensajes, como se muestra en la
Figura 4:

Obj eto
Gestores

Obj eto
Obj eto
EntryPoint

Obj eto

Figura 4. Arquitectura Orientada a Objetos


Fuente: (Ahumada Ahumada, 2013)
Elaboracin: Autor

Arquitectura Orientada a Servicios: Estilo SOA permite un diseo para la integracin de


aplicaciones independientes a travs de la red, disponiendo sus funcionalidades por medio
de servicios. Los servicios web constituyen una base importante para la implementacin
de este estilo arquitectnico, se basa en estndares como SOAP, WDSL, UDDI, XML, etc.

14

SOA permite descomponer aplicaciones monolticas en servicios independientemente de


la plataforma en que estn construidas, e implementar estas funcionalidades en forma
modular, Figura 5. El tema SOA ser profundizado ms adelante.

Registro de
Servicios

Encontrar

Solicitante del
Servicio

Transmitir

Unir (SOAP)

Proveedor del
Servicio
Servicio

Figura 5. Arquitectura Orientada a Servicios


Fuente: (Sommerville, 2011)
Elaboracin: Autor

En un estilo arquitectnico se definen los componentes, conectores y las interfaces de la aplicacin,


se detallan cmo los componentes y los conectores pueden configurarse en un sistema de
software. As mismo los estilos arquitectnicos contienen un conjunto de las limitaciones que
establecen las funciones de los componentes arquitectnicos y sus relaciones.
En resumen, la arquitectura de un sistema de software puede basarse en uno o en varios estilos
arquitectnicos, los cuales describen:

Un conjunto de componentes con sus responsabilidades.

Un conjunto de conectores entre componentes.

Restricciones que definen como se integran los componentes.

Modelo de las propiedades del sistema.

SOA como tema principal del presente trabajo, ser abordado a profundidad ms adelante, donde
se ver sus principios, caractersticas, elementos, capas, etc.

15

1.3. Patrones
1.3.1.

Patrones Arquitectnicos

Sommerville (2011) define los patrones arquitectnicos como:


Una descripcin abstracta estilizada de buena prctica, que se ensay y se puso a prueba
en diferentes sistemas y entornos. De este modo, un patrn arquitectnico debe describir
una organizacin de sistemas que han tenido xito en sistemas previos. Debe incluir
informacin sobre cundo es y cundo no es adecuado usar dicho patrn, as como las
fortalezas y debilidades del patrn. (p. 156)
Para Venete (2011) los patrones arquitectnicos ofrecen soluciones a problemas de ingeniera de
software especificando un conjunto de componentes con sus respectivas responsabilidades y
recomendaciones de cmo organizar estos componentes.
Un patrn consta de 3 partes segn Camacho et al., (2004):

Contexto.- Situacin de diseo en la que aparece un problema de diseo.

Problema.- Conjunto de fuerzas que aparecen repetidamente en el contexto.

Solucin.- Configuracin que equilibra estas fuerzas. Que abarca:


o

Estructura de componentes y relaciones.

Comportamiento a tiempo de ejecucin: aspectos dinmicos de la solucin, como


la colaboracin entre componentes, la comunicacin entre ellos, etc.

Los patrones arquitectnicos son medios para reutilizar el conocimiento sobre las arquitecturas de
sistemas, describen la arquitectura definiendo la estructura bsica del sistema; representa una
plantilla de construccin que provee un conjunto de subsistemas con sus responsabilidades, que
facilitan el diseo arquitectnico.
El diseo arquitectnico es la base fundamental de toda aplicacin, porque en l se establecen los
subsistemas y la comunicacin entre ellos. Un buen diseo arquitectnico tiene como ventajas:
una buena comunicacin entre los actores del sistema, anlisis del sistema y la reutilizacin.
Tipos de los Patrones Arquitectnicos.
Los patrones arquitectnicos son plantillas que sirven para representar una arquitectura especfica,
y de acuerdo a las necesidades del sistema se elige la adopcin de una en particular, algunos
ejemplos de patrones arquitectnicos son:

16

Modelo-Vista-Controlador.

Capas.

Repositorio.

Cliente-Servidor.

Arquitectura Tubera y Filtro.

En la Tabla 1, se describen algunos de los patrones arquitectnicos ms conocidos tomados de


Sommerville (2011) y Almeida & Perez (2011):

17

Tabla 1. Patrones arquitectnicos

PATRON

Modelo Vista
Controlador

DESCRIPCION

VENTAJAS

DESVENTAJAS

Define el modelo de datos, la presentacin y las


acciones de la aplicacin en tres capas distintas:

Permite que los datos cambien de manera


independiente de su representacin y viceversa.

Puede implicar cdigo adicional y complejidad


de cdigo cuando el modelo de datos y las
interacciones son simples.

Modelo: Controla el acceso y comportamiento de


los datos del dominio de aplicacin.

Soporta en diferentes formas la presentacin de


los mismos datos, y los cambios en una
representacin se muestran en todos ellos.

Vista: Se encarga de la visualizacin de la


informacin en el cliente.
Controlador: Define los eventos o acciones del
usuario, invocando peticiones al modelo y enva la
respuesta a la vista para la presentacin.
Se definen distintas capas en la aplicacin de manera
que slo se comunican entre s las capas adyacentes.

Capas

Favorece el bajo acoplamiento.


Este es el estilo arquitectnico empleado en las
aplicaciones web convencionales.
Todos los datos en un sistema se gestionan en un
repositorio central, accesible a todos los componentes
del sistema. Los componentes no interactan
directamente, sino tan slo a travs del repositorio.

Repositorio

Permite la sustitucin de capas completas en


tanto se conserve la interfaz.
Para aumentar la confiabilidad del sistema, en
cada capa pueden incluirse facilidades
redundantes (Autenticacin).

Los componentes pueden ser independientes,


no necesitan conocer la existencia de otros
componentes. Los cambios hechos por un
componente se pueden propagar hacia todos los
componentes.
La totalidad de datos se puede gestionar de
manera consistente, pues todos estn en un
lugar.

Cliente
Servidor

La funcionalidad del sistema se organiza en servicios, y


cada servicio lo entrega un servidor independiente. Los
clientes son usuarios de dichos servicios y para
utilizarlos ingresan a los servidores.

Los servidores se pueden distribuir a travs de


una red.

Separacin difcil entre capas, y es posible que


una capa de nivel superior deba interactuar
con una capa de nivel inferior.
Rendimiento suele ser un problema, debido a
mltiples niveles de interpretacin de una
solicitud de servicio mientras se procesa en
cada capa.
El repositorio es un punto de falla nico, de
modo que los problemas en el repositorio
afectan a todo el sistema.
Es posible que haya ineficiencias al organizar
toda la comunicacin a travs del repositorio.
Quiz sea difcil distribuir el repositorio por
medio de varias computadoras.
Cada servicio es un punto de falla, de modo
que es susceptible a ataques de rechazo de
servicio o a fallas del servidor.

La funcionalidad general estara disponible a


todos los clientes, as que no necesitan
implementarse en todos los servicios.

El rendimiento resultar impredecible porque


depende de la red, as como del sistema.
Problemas administrativos cuando los
servidores sean de propiedad de diferentes
organizaciones.

Se aplica cuando los datos de entrada se han de


transformar en datos de salida mediante una serie de
operaciones.

Tubera y Filtro

Los componentes (filtros) van transmitiendo datos al


siguiente por medio de tuberas.
Los filtros no necesitan saber el funcionamiento de los
vecinos. Slo se preocupan de su entrada y su salida.

Fcil de entender y soporta reutilizacin de


transformacin.
La evolucin al agregar transformaciones es
directa.
Puede implementarse como un
secuencial o como uno concurrente.

sistema

El formato para la transferencia de datos debe


acordarse entre las transformaciones que se
comunican.
Cada transformacin debe analizar sus
entradas y sintetizar sus salidas al formato
acordado.
Carga aumentada del sistema, lo que hace
imposible
reutilizar
transformaciones
funcionales que usen estructuras de datos
incompatibles.

Si hay una sola lnea de transformaciones se denomina


procesamiento por lotes secuencial (pipeline).
Fuente: (Almeida & Perez, 2011; Sommerville, 2011)
Elaboracin: Autor

19

Los patrones arquitectnicos ofrecen soluciones a problemas de arquitectura de software


en ingeniera de software. Proveen una descripcin de los elementos y el tipo de relacin que tienen
con un conjunto de restricciones sobre cmo pueden ser usados, representando un esquema
estructural y fundamental del sistema software y sus elementos.
1.3.2.

Patrones de Diseo.

El patrn de diseo es una descripcin del problema y la esencia de su solucin, de modo que la
solucin puede reutilizarse en diferentes configuraciones; no es una especificacin detallada
(Sommerville, 2011). Los patrones representan una forma de describir las mejores prcticas de
diseo para poderlos reutilizar, as mismo detallan aspectos relacionados con el diseo de los
subsistemas, centrndose en aspectos ms especficos de la aplicacin; los patrones de diseo
son la base para la bsqueda de soluciones a problemas comunes en el desarrollo de software y
para el diseo de interfaces.
Sommerville (2011) presenta 4 elementos que conforman los patrones de diseo:

Nombre significativo.

Descripcin del rea problemtica.

Descripcin de la solucin, relaciones y responsabilidades.

Estado de las consecuencias, resultados y negociaciones al aplicar el patrn.

Caractersticas de los Patrones de Diseo.


Los patrones de diseo ayudan a un diseador a lograr un buen diseo ms rpidamente, haciendo
que sean ms fciles reutilizar diseos y arquitecturas, utilizando tcnicas que ya han sido
probadas anteriormente. Cada patrn de diseo se centra en un problema concreto, describiendo
cuando y como utilizarlo. Las principales caractersticas de los patrones de diseo son:

Ser efectivo para resolver problemas similares.

Reutilizable.

Aplicable a diferentes problemas de diseo en distintas circunstancias

Proporcionar catlogos de elementos reusables en el diseo de sistemas software.

Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y


solucionados anteriormente.

Formalizar un vocabulario comn entre diseadores.

Estandarizar el modo en que se realiza el diseo.

Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando


conocimiento ya existente.

Los patrones de diseo son soluciones bien pensadas a problemas conocidos de la programacin,
ya que abstraen el comportamiento de un determinado problema en una configuracin de
componentes y estn clasificados de acuerdo con el nivel de abstraccin que tenga cada patrn.
Tipos de Patrones de Diseo.
Un patrn de diseo puede considerarse como un documento que define una estructura de clases
que aborda una situacin particular. Los patrones de diseo se dividen en tres grupos principales
(Tedeschi, 2014):

Patrones Creacionales: se encargan de la inicializacin, configuracin de objetos y


creacin de instancias. Resuelven problemas relacionados con la creacin de instancias
de objetos.

Patrones Estructurales: Se encargan de

aislar la interfaz de la implementacin, es

decir, definen como las clases y objetos se asocian para formar estructuras ms
complejas.

Patrones de Comportamiento: Se encargan de la descripcin de las clases y objetos


y la comunicacin e interaccin entre ellos en tiempo de ejecucin.

En la Tabla 2, se resumen los diferentes patrones de diseo de acuerdo a su clasificacin de


Almeida & Perez (2011):

21

Tabla 2. Patrones de diseo


PATRON

Abstract Factory
(Creacional)

DESCRIPCIN

Crea familias de objetos


relacionados o dependientes sin
necesidad de especificar su
clase concretamente

SE USA CUANDO
* Ser independiente de cmo se crean, se componen y se representan sus productos.
* Debera ser configurado mediante una de las mltiples familias de productos posibles.
* Se disea una familia de objetos relacionados que deben ser usados en conjunto.
* Proveer una librera de una clase de productos y es necesario revelar simplemente sus interfaces, pero
ocultar sus implementaciones.

Builder
(Creacional)

Separa
el
proceso
de
construccin de un objeto
complejo de su representacin,
para que el mismo proceso de
construccin
pueda
crear
diferentes representaciones

* El algoritmo para crear objetos complejos debe ser independiente de las partes que constituyen el objeto
y la forma en que son ensamblados.

Crea
objetos
nuevos
copindolos, clonando una
instancia creada previamente

* Las clases a instanciar son especificadas en tiempo de ejecucin

Prototype
(Creacional)

* La construccin de procesos debe permitir diferentes representaciones para el objeto que se construye.

* Para evitar la construccin de una jerarqua de la clase de fbricas que se asemeja a la jerarqua de la
clase de productos
* Cuando instancias de una clase pueden tener una de las combinaciones de diferentes estados.
* Cuando es necesario la creacin de distintas variantes de un objeto. Entonces, el cdigo que utilizan esos
objetos solicitar una copia del objeto que necesite, una copia significa otra instancia del objeto. El nico
requisito que debe cumplir el objeto es la posibilidad de clonarse.

Adapter
(Estructural)

Sirve para convertir una interfaz


de una clase en otra, haciendo
que una clase a la que le fuera
imposible utilizar la primera
interface, haga uso de ella por
medio de la segunda. Es decir,
permite que stas trabajen
juntas, lo que de otra forma sera
incompatible

* Es necesario el uso de una clase existente, y su interfaz es distinta a la que se necesita.


* Se requiere crear una clase reusable que coopere con clases no relacionadas, es decir, con clases que
no necesariamente tienen interfaces compatibles.

Bridge (Estructural)

Mediante el patrn Bridge es


posible
desacoplar
una
abstraccin
de
su
implementacin, de forma que
ambas puedan modificarse de
manera
independiente
sin
necesidad de alterar por ello la
otra.

* Se desea evitar una vinculacin permanente entre la abstraccin y su implementacin. Este puede ser el
caso en que la implementacin debe ser seleccionada o modificada en tiempo de ejecucin.
* Las abstracciones y sus implementaciones deben ser extensibles a travs de subclases. En este caso, el
patrn Bridge permite combinar diferentes abstracciones e implementaciones y extenderlas en forma
independiente.
* Los clientes no deben tener que recompilar el cdigo cuando se lleven a cabo modificaciones en la
implementacin de una abstraccin.
* Se desea ocultar completamente la implementacin de una abstraccin a los clientes.
* Se necesita compartir una implementacin entre varios objetos, y este hecho debe ocultarse a los clientes.

Composite
(Estructural)

Facade
(Estructural)

Admite
construir
objetos
complejos por medio de la
composicin recursiva de objetos
similares u otros ms simples en
una estructura en forma de rbol.
Adems permite que dichos
objetos sean tratados de manera
semejante, sin hacer distinciones
entre ellos.
Simplifica el acceso a un
conjunto
de
clases
proporcionando una nica
clase que todos utilizan para
comunicarse
con
dicho
conjunto de clases.

* Es necesario representar la jerarqua completa de objetos.


* Se necesita que el cliente no note la diferencia entre una composicin de objetos y un objeto individual,
de esta forma el cliente tratar a todos los objetos en la composicin de la estructura uniformemente.

* Los clientes no necesitan conocer las clases que hay tras la clase Facade.
* Quiere proveer una interfaz nica para un subsistema complejo. Esto ayuda a que un subsistema sea
ms reusable y fcil de adaptar.
* Hay muchas dependencias entre clientes y clases que implementan una abstraccin. Con el patrn
Facade se desacopla el cliente del subsistema, as como entre subsistemas; esto promueve subsistemas
independientes y portables.
* Usted quiere dividir en capas su subsistema.

23

Data
Access
Object (Estructural)

DAO define un interfaz con


operaciones para insertar, borrar,
actualizar y recuperar los objetos
persistentes de un tipo.

* Para abstraer y encapsular todos los accesos a la fuente de datos.


* Desacoplar la lgica de negocio de la lgica de acceso a datos, de manera que se pueda cambiar la
fuente de datos fcilmente.
* Para manejar la conexin con la base de datos y para manejar las operaciones CRUD.
* Poder seleccionar la fuente de datos durante la instalacin o configuracin de la aplicacin.

Se emplea como intermediario


para acceder a un objeto,
controlando el acceso a l.

* Un proxy remoto provee una representacin local de un obj* Para abstraer eto ubicado en un espacio de
direccin diferente.
* Un proxy virtual crea objetos de gran tamao bajo demanda.

Proxy (Estructural)
* Un proxy de proteccin controla el acceso al objeto original, controlando quien accede a cada mtodo y
otorgando los permisos basndose en el invocador.
* Una referencia elegante lleva a cabo acciones extras cuando se acceden a objetos referenciados.

Observer
(Comportamiento)

Command
(Comportamiento)

Define una dependencia del tipo


uno-a-muchos entre objetos, de
manera que cuando uno de los
objetos cambia su estado, el
observer se encarga de notificar
este cambio a todos los otros
objetos dependientes.
Permite solicitar una operacin a
un objeto sin conocer realmente
el contenido de esta operacin, ni
el receptor real de la misma. Para
ello se encapsula la peticin
como un objeto, facilitando la
parametrizacin de los mtodos.
Al encapsular un mensaje como

* Una abstraccin tiene dos aspectos, uno dependiente del otro. Encapsulndolos en objetos separados
se permite variarlos y reusarlos de forma independiente.
* Cuando un cambio en un objeto implica cambiar otros y no se conoce de antemano cuantos objetos
deben actualizarse
* Cuando un objeto debe ser capaz de hacer notificaciones a otros sin hacer suposiciones de quines son,
buscando un bajo acoplamiento.
* Facilitar la parametrizacin de las acciones a realizar
* Independizar el momento de peticin del de ejecucin
* Implementar CallBacks, especificando que rdenes se necesitan ejecutar en ciertas situaciones bajo otras
rdenes. Es decir, un parmetro de una orden puede ser otra orden a ejecutar. .
* Dar soporte para deshacer comandos, procesos de identificacin y/o transacciones

24

un objeto, permite gestionar


colas o registros de mensajes,
deshacer
operaciones
y
restaurar el estado a partir de un
momento dado.

* Desarrollar sistemas utilizando rdenes de alto nivel que se construyen con operaciones sencillas
(primitivas).

* El comportamiento de un objeto depende de su estado y este cambia con mucha frecuencia.

State
(Comportamiento)

Permite que un objeto cambie en


tiempo
de
ejecucin
su
comportamiento cuando cambia
su estado interno.

Strategy
(Comportamiento)

Define una familia de algoritmos,


encapsula cada uno y los hace
intercambiables, permitiendo que
el
algoritmo
vare
independientemente del cliente
que haga uso de l.

* Los mtodos tienen largas y mltiples sentencias condicionales que dependen del estado del objeto.
Estos estados generalmente son representados por constantes enumeradas y largas sentencias
switch/case dentro de los mtodos. El patrn State ubica cada rama del condicional en clases separadas.
* Se quiera ofrecer la posibilidad de configurar una clase con una gama de comportamientos disponibles.
* Se necesiten diferentes variantes de un algoritmo.
* Un algoritmo use datos que el cliente no tenga por qu conocer.
* Una clase defina varios comportamientos y estos aparezcan en forma condicional en sus operaciones.

Fuente: (Almeida & Perez, 2011)


Elaboracin: Autor

25

En la Figura 6, se representa la relacin que existe entre los estilos arquitectnicos, patrones
arquitectnicos y los patrones de diseo, que propone el desarrollo de arquitecturas de software
como un sistema de patrones, y distintos niveles de abstraccin. Los estilos y patrones ayudan al
arquitecto a definir la composicin y el comportamiento del sistema de software, y una combinacin
adecuada de ellos permite alcanzar los requerimientos de calidad. Los patrones arquitectnicos en
comparacin con los patrones de diseo, los patrones arquitectnicos tienen un nivel de
abstraccin mayor.

Figura 6. Relacin de abstraccin entre estilos y patrones arquitectnicos


Fuente: (Camacho et al., 2004)
Elaboracin: Autor

En la Tabla 3, para tener una idea ms clara se muestra las diferencias entre estilo arquitectnico
y patrn arquitectnico:
Tabla 3. Diferencias entre estilos arquitectnicos y patrones arquitectnicos

ESTILOS ARQUITECTNICOS

PATRN ARQUITECTNICO

Solo describe el esqueleto estructural y


general de las aplicaciones.

Existen en varios rangos de escala, comenzando con


patrones que definen la estructura bsica de una
aplicacin.

Son independientes del contexto al que


puedan ser aplicados.

Partiendo de la definicin de patrn, requieren de la


especificacin de un contexto del problema.

Cada estilo es independiente de los otros.

Depende de patrones ms pequeos que contiene,


patrones con los que interacta, o de patrones que lo
contengan.

Expresan tcnicas de diseo desde una


perspectiva que es independiente de la
situacin actual del diseo.

Expresa un problema recurrente de diseo muy


especfico, y presenta una solucin para l, desde el punto
de vista del contexto en el que se presenta.

Son una categorizacin de sistemas.

Son soluciones generales a problemas comunes.

Fuente: (Camacho et al., 2004)


Elaboracin: Autor

El estilo y el patrn arquitectnico imponen una transformacin en el diseo de una arquitectura,


pero el alcance del patrn es menor que el del estilo, ya que el patrn se concentra en un solo
aspecto en lugar de toda la aplicacin. Los patrones arquitectnicos abarcan aspectos de
comportamiento dentro del contexto de la arquitectura. El uso en conjunto de los estilos y los
patrones sirven para determinar la forma de la estructura general de un sistema, y es muy
importante evaluar si un patrn es apropiado para la aplicacin y el estilo arquitectnico en general.
Los servicios web proporcionan rutinas que pueden ser utilizadas por cualquier desarrollador y
stos pueden estar alojados en un servidor; adems son una forma de implementar la arquitectura
orientada a servicios y son independientes de la plataforma con la que SOA puede descomponer
las aplicaciones. A continuacin se profundizar el tema de servicios web.
1.4. Servicios web.
1.4.1.

Definicin

Un servicio es un mecanismo que permite el acceso a una o ms capacidades, donde se


proporciona el acceso mediante un interfaz prescrito y se ejerce de conformidad con las
limitaciones y las polticas como se especifica en la descripcin del servicio(N. Fernndez, 2012).
C. Reynoso & Kicillof (2004) menciona un concepto de servicio web que proporciona la W3C: es
un software que permite la interaccin entre diferentes mquinas conectadas por internet, posee
una interfaz (WSDL) que se comunica con el cliente por medio de mensajes SOAP en formato
XML, comnmente transportados por medio del protocolo HTTP en conjunto con otros estndares
de los servicios web.
Segn Sommerville (2011), un servicio web es una funcin ofrecida por una parte a otra. Aunque
el proceso puede asociarse a un proceso fsico, la funcin es esencialmente intangible y, por lo
general, no da por resultado la propiedad de alguno de los factores de produccin.

27

Anaya Lopez (2011) menciona que los servicios web se describen as mismos como la lgica de
negocio expuesto en la web como servicios por medio de interfaces y el uso de protocolos de
internet, que pueden ser buscados, suscritos e invocados por otra aplicacin.
Los servicios web son aplicaciones que estn identificadas por un Uniform Resource Identiflier
(URI) que tienen la capacidad de estar definidos, descritos, descubiertos e invocados mediante
XML. Los servicios web interactan en internet, intercambian informacin entre s con el objetivo
de ofrecer servicios, mediante la adopcin de protocolos y estndares.
1.4.2.

Estructura y caractersticas de los Servicios Web

Los servicios web proveen una funcionalidad a otros usuarios o a otros servicios, lo que determina
servicios como Proveedores y servicios Consumidores, interactuando mediante mensajes.
Gonzles Quiroga (2011) menciona 3 elementos de los servicios:

Contrato.- En el contrato se especifica la funcionalidad, propsito, restricciones y el


modo de uso del mismo.

Implementacin.- La funcionalidad del servicio implementada bajo alguna tecnologa

Interfaces.- Provee la forma de acceder a la funcionalidad de acuerdo al contrato.

Estos componentes tambin forman parte de los elementos de una arquitectura orientada a
servicios ya que los servicios lo son, y las caractersticas principales de los servicios web, segn
Aperador (2012) son las siguientes:

Uso de estndares, para que los servicios web sean utilizados por sistemas
heterogneos existentes en la red es el empleo del protocolo de transferencia de
datos HTTP utilizado por todos los navegadores web y XML.

Basados en tecnologas de paso de mensajes, la interaccin entre el cliente y el


proveedor del servicio es empaquetada en unidades denominadas mensajes.

Los servicios web presentan una funcionalidad de caja negra que puede ser reutilizada
sin preocuparse de cmo es implementada y ello proporciona interfaces bien definidas.

Su contenido y funcionamientos es de fcil acceso.

Permiten la composicin de servicios ms complejos mediante su combinacin e


integracin

Pueden ser consumidas por cualquier tipo de aplicacin.

28

1.4.3.

Especificaciones de los servicios web

Para Chase (2011) las especificaciones de los servicios web estn clasificadas en dos grupos,
Como se puede observar en la Figura 7:

Especificaciones bsicas:
o

SOAP: Simple Object Access Protocol, detalla el formato de los mensajes y la


forma en que las aplicaciones utilizan el contenido del mensaje, como por
ejemplo los elementos del header, body, lo que permite que el mensaje transite
entre mltiples intermediarios hasta llegar a su destino.

WSDL: Web Services Description Language, detalla una forma estndar de que
un servicio web basado en el protocolo SOAP pueda ser descrito, incluyendo la
forma la forma de uso del mensaje, su ubicacin, puertos, etc.

UDDI: Universal Description, Discovery and Integration, permite una forma de


registrar los servicios web, es decir es como un directorio de servicios web en la
cual se puede buscar los servicios que se desea utilizar.

Especificaciones ampliadas
o

WS-Security: Esta especificacin provee de mecanismo de seguridad tales


como la autenticacin, la autorizacin, el encriptado y el firmado digital, lo que
permite la implementacin de servicios web seguros, protegiendo la
informacin.

WS-Policy: Es una extensin de WS-Security, que permite detallar las


restricciones de uso del servicio web.

WS-I: Proporciona un conjunto de estndares y prcticas para promoverla


interoperabilidad sobre cualquier plataforma basados en estndares XML.

WS-BPEL: Es un lenguaje para la especificacin de la composicin de servicios


web.

29

Especificaciones Ampliadas

Integracin

WS-BPEL, WS-CDL, WS-Cordination, WS-Transaction

Calidad del
Serv icio

WS-Security, WS-Reliable, WS-Policy, WS-Interoperability

Especificaciones Bsicas

Descubrimiento

UDDI

Descripcin

WSDL

Mensaj era

SOAP, XML

Transporte

HTTP, SMTP

Figura 7. Especificaciones de los servicios web


Fuente: (Arias & Fernndez, 2009)
Elaboracin: Autor

Los servicios web funcionan como aplicaciones independientes ya que se incluyen lgica de
negocios, manejo de datos, procedimientos y polticas para la resolucin de un problema
especfico. Los servicios web sirven de base para la implementacin de SOA permitiendo la
comunicacin por medio de mensajes de diferentes sistemas independientemente del sistema
operativo o lenguaje de programacin utilizado. La comunicacin entre los servicios web se basa
en el estndar XML y mediante el protocolo SOAP.
Los servicios web hacen uso de una pila de estndares y especificaciones que permiten la
interoperabilidad como: SOAP para el paso de mensajes, WSDL para la descripcin de los
servicios web, UDDI para el descubrimiento de los servicios web. Adems como de otras
especificaciones para la calidad y seguridad de los servicios web como: WS-Policy. WS-Security,
WS-Addressing, etc.

30

1.4.4.

Ventajas y desventajas de los Servicios Web

En la Tabla 4, se listan las ventajas y desventajas que ofrecen los servicios web tomado de
Ordez Len (2010):
Tabla 4. Ventajas y desventajas de los servicios web

VENTAJAS

DESVENTAJAS

Estandarizacin, los servicios web se basan en


especificaciones, protocolos y estndares para el
intercambio de datos, mensajes, bsqueda y
descripcin.

Problemas en el desempeo, los cuellos de


botella son tpicamente cdigo que podra
perfeccionarse, una necesidad para ms
servidores, o una necesidad para una conexin a
Internet ms rpida.

Fcil implementacin, se apoya en HTTP que es un


protocolo universal para el acceso en la web. Adems
para el desarrollo de servicios web existen
herramientas que permiten su fcil implementacin.

Inseguridad, al apoyarse en HTTP, se saltan la


seguridad basada en firewall que auditan la
comunicacin entre programas a ambos lados de
la barrera.

Integracin, los servicios web que se encuentren en


diferentes lugares geogrficos pueden ser integrados
y combinados para crear nuevos servicios web.

Rendimiento, en comparacin con otros modelos


de computacin distribuida su rendimiento es
bajo.

Interoperabilidad, los servicios web permiten la


interoperabilidad de distintos sistemas por medio de
la comunicacin de estndares abiertos como XML y
HTTP. Adems permiten la interoperabilidad de
diversos servicios web implementados en diferentes
plataformas o lenguajes de programacin.

Interdependencia, el servicio web agregado


depende de para su funcionamiento apropiado de
los servicios de web ms pequeos.

Accesibilidad, los servicios web son completamente


accesibles a travs de la red por cualquier tipo de
dispositivo con internet.
Software como servicio, los servicios web pueden ser
publicados y accedidos desde cualquier plataforma
web sin importar el lugar donde se encuentre o en que
lenguaje est desarrollado, ya que es accedido por
protocolos y estndares abiertos.
Fuente: (Ordez Len, 2010)
Elaboracin: Autor

Los servicios web se pueden implementar siguiendo los principios de SOA, ya que permite mayor
acoplamiento, mediante el establecimiento de un Contrato, a diferencia de los servicios web REST
(Respresentational State Transfer) o RCP (Remote Procedure Call). La arquitectura orientada a
servicios permite disear e implementar los procesos de negocios en forma de servicios,
obteniendo una gran flexibilidad, resolviendo problemas de conectividad gracias a que permite la

31

reusabilidad y la independencia de plataformas. A continuacin se procede a profundizar en la


arquitectura orientada a servicios.
1.5. Arquitectura Orientada a Servicios.
1.5.1.

Definicin

SOA (Service Oriented Architecture, en sus siglas en ingls), tiene varios enfoques: de negocio, de
tecnologa y de organizacin. Desde el punto de vista de negocio, SOA permite a las
organizaciones satisfacer los cambios en las necesidades de la empresa, mediante la
implementacin de servicios web. Desde el punto de vista tecnolgico aumenta la flexibilidad
simplificando a adaptacin de los sistemas existentes, mejora la productividad de procesos y la
usabilidad de las aplicaciones. Desde el punto de vista organizacional permite la consistencia en
los procesos, ofrece rapidez de adaptacin al cambio y mejora la cultura de servicio.
Lewis (2008) del SEI, menciona que arquitectura orientada a servicios es una forma de diseo,
desarrollo, implementacin y gestin de sistemas, en el cual:

Los servicios proporcionan funcionalidad de negocio reutilizables.

Los consumidores de servicios se construyen utilizando la funcionalidad de los servicios


disponibles.

Las definiciones de interfaz de servicio son artefactos de primera clase.

Una infraestructura SOA permite el descubrimiento, la composicin y la invocacin de


servicios.

El intercambio de documentos basados en mensajes.

Serrano (2007) conceptualiza la arquitectura orientada a servicios en trminos de servicios


programables que ofrecen una funcionalidad encapsulada dbilmente acoplados, proporcionados
por aplicaciones nuevas o existentes, con la finalidad de poder ser reutilizados por aplicaciones
finales u otros servicios.
En s, SOA es arquitectura de referencia basada en servicios, es un marco de diseo para la
integracin de aplicaciones independientes de manera que se pueda acceder desde la red por
medio de servicios web. Los servicios web son la unidad de software con una funcionalidad mnima.
SOA permite que distintos sistemas, escritos en diferentes lenguajes de programacin puedan
convertirse en servicios integrados e interoperables en la web.

32

En la Figura 8 se observa la integracin de SOA en una sola aplicacin final de usuario, donde la
aplicacin final orquesta la ejecucin de un conjunto de servicios, aade la lgica y la presenta a
mediante un interfaz al usuario. La orquestacin es un tema que se abordar ms adelante.

Cliente 1

Cliente 2

Cliente 3

Cliente 4

Node1

Serv idor de
Aplicaciones

Servicio
Web
Sistema de
Mensaj era
Jav a, IBM

Servicio
Web

Serv idor
Comercial

Serv idor
Cliente Mov il

Servicio
Web

Servicio
Web

Bus de Serv icios Empresariales


Servicio
Web

Servicio
Web

Mainframes y
Microcomputadores

Servicio
Web

Serv idor
de Base
de Datos

Serv idor de
Correo
Electrnico

Figura 8. Integracin SOA


Fuente: (Enriquez Huaca & Caraguay, 2011)
Elaboracin: Autor

1.5.2.

Principios de la Orientacin a Servicios.

Para desarrollar aplicaciones orientadas a servicios, es conveniente tener en cuenta ciertos


principios que nos ayudan a tener un buen diseo. Existen principios que permiten verificar si una
aplicacin sea realmente una aplicacin SOA. Los principios que propone Thomas Erl en sus
publicaciones sobre la orientacin a servicios son:

Ser reutilizables.- Los servicios deben ser diseados para ser reutilizados dentro de la
misma aplicacin, dentro del dominio de aplicaciones de la empresa o incluso dentro
del dominio pblico.

33

Contrato formal.- Los servicios deben poseer un contrato formal en el cual debe
constar: nombre del servicio, forma de acceso, funcionalidades que ofrece, datos de
entrada y salida de las funcionalidades. Mediante el contrato el consumidor acceder a
ste, en los servicios se lo logra mediante WSDL.

Bajo acoplamiento.- Los servicios deben ser independiente unos de otros, es decir
debe existir bajo acoplamiento entre el servicio que se va a ejecutar y el servicio que lo
llama, logrando as su total reutilizacin.

Permitir la composicin.- Los servicios deben permitir construir servicios genricos de


ms alto nivel, el cual est constituido de servicios de ms bajo nivel. Esto se logra
mediante protocolos para orquestacin (WS-BPEL) y coreografa (WS-CDL).

Autonoma.-Todo servicio debe poseer su propio entorno de ejecucin, de tal manera


que el servicio es independiente y reutilizable.

Sin estado.- Un servicio no debe guardar ningn tipo de informacin, para poder ser
secuenciados (orquestados) para realizar la lgica del negocio y evitar problemas de
inconsistencia; y que toda la informacin est almacenada en algn tipo de sistema de
informacin.

Ser descubiertos.- Todo servicio debe ser descubierto de alguna forma para que
pueda ser utilizado, el descubrimiento de servicios web se lo realiza mediante interfaces
de registros UDDI.

Todos estos principios se encuentran interrelacionados entre s, como se puede observar en la


Figura 9, al momento de querer implementar una arquitectura orientada a servicios, teniendo como
objetivo principal la Reusabilidad, a travs de los dems principios mencionados, es decir que el
servicio debe ser diseado para ser reusado y formar aplicaciones ms robustas y competitivas.

34

Contrato
Formal

Descubrimiento

Evita
duplicidades y
se obtiene la

Proporciona la
independencia
de servicios por
ende la

Baj o
Acoplamiento

Minimiza las
dependencias
consiguiendo la

Reusabilidad
Ofrece mas
oportunidades de
Sin Estado

Permite la

Independencia
del entorno de
ejecucin
consiguiendo la

Composicin

Autonoma

Figura 9. Interrelacin entre los Principios SOA


Fuente: (Arsanjani, 2004)
Elaboracin: Autor

1.5.3.

Caractersticas de un servicio web SOA

Un servicio es un elemento que encapsula una funcionalidad atmica, usado para soportar los
servicios de negocio que la organizacin proporciona. En un ambiente SOA, los servicios son
estructuras pequeas utilizadas para la construccin de estructuras ms complejas, para satisfacer
una necesidad especifica.
Para ello, Gomez (2013) enumera algunas caractersticas que un servicio web SOA debe cumplir:

Definido: El servicio debe definir lo que hace, sus procesos de negocio, su interfaz de
comunicacin, su forma de invocacin, los datos de entrada y salida y la forma en que
debe ser manejado el servicio.

Implementado: El servicio debe estar desarrollado, construido o implementado de


alguna forma con alguna herramienta.

Desplegado: Debe estar disponible para su respectivo uso por otras aplicaciones
clientes.

35

Manejado: El servicio debe estar controlado o monitorizado y en constante


mantenimiento para verificar su disponibilidad.

Reusable: Para que el servicio pueda ser reutilizado por cualquier proceso de negocio,
ste debe estar disponible cuando lo requieran.

Comunicacin: La accesibilidad al servicio se lo debe hacer mediante el envo y


recepcin de mensajes en el estndar XML y SOAP.

Abstraccin: La lgica de cmo es la implementacin del servicio debe estar oculto, y


ser utilizado solamente mediante su definicin.

Orquestado: Un servicio debe permitir ser orquestado, es decir ser combinado para
formar servicios ms grandes y complejos.

Granularidad: Se refiere a la complejidad del servicio, es decir que mientras ms


sencilla sea la complejidad, la funcionalidad es mejor; no debe poseer una funcionalidad
compleja sino mediante el orquestamiento.

Desacoplamiento: El servicio debe depender lo menos posible de otro servicio para


que permita el desacoplamiento, y cuando se necesite modificar un servicio no afecte a
los dems servicios.

Adems, para que un servicio web se considere un servicio SOA, se debe implementar los
estndares de la industria incluyendo las especificaciones de los servicios web: XML, HTTP,
SOAP, WSDL, UDDI, WS-Security, etc.
1.5.4.

Ventajas y desventajas de SOA

SOA es un nuevo estilo arquitectnico que est orientada a servicios y que gracias a su flexibilidad
hace ms fcil implementar cambios en toda la empresa, sin embargo no todas la empresas tienen
las mismas necesidades de negocio por tal motivo la empresa debe evaluar si es conveniente o
no adoptar SOA a su organizacin; En la Tabla 5, se listan algunas de las ventajas y desventajas
que tiene SOA tomados de Arquitectura Orientada a Servicios (2011) y Enriquez Huaca &
Caraguay (2011):

36

Tabla 5. Ventajas y desventajas de la Arquitectura Orientada a Servicios

VENTAJAS

DESVENTAJAS

Transforma los procesos de negocio en servicios


compartidos con menor coste de mantenimiento.

SOA depende de la implementacin de estndares, ya


que la comunicacin entre aplicaciones sin estndares
requiere de mucho tiempo y cdigo

Rpida adaptacin y despliegue de servicios.


Aplicaciones ms seguras y manejables.

SOA no se aplica para sistemas con alto nivel de flujo


de datos, ni para sistemas con periodo de vida corto, ni
para aplicaciones que no requieran de implementacin
del tipo Request-Response.

Adaptabilidad a cambios aadiendo flexibilidad y


reduciendo el esfuerzo.

SOA es todava un tema nuevo, todava se est


buscando la mejor prctica y especificar las normas.

Reutiliza los servicios compartidos que han sido


desplegados previamente.

Para implementar SOA es necesario conocer los


procesos del negocio, clasificarlos de acuerdo a
funcionalidades similares, y con ellas formar una capa
de servicio que se puedan reutilizar por cualquier
proceso.

Integra aplicaciones heredadas limitando as el


coste de mantenimiento e integracin.

El problema en la organizacin, la cultura y la poltica,


las personas no estn dispuestas a aceptar el cambio
y compartir recursos.

Beneficios en el desarrollo, los servicios al ser


reutilizables, se tiene la capacidad ampliar sus
funcionalidades de forma segura.

La implementacin de un servicio en la empresa puede


traer efectos negativos en los procesos de negocio de
la misma.

Evita que los proyectos tomen largos tiempo de


duracin ya que permite la creacin y cambios de
servicios en forma incremental.
Fuente: (Arquitectura Orientada a Servicios, 2011; Enriquez Huaca & Caraguay, 2011)
Elaboracin: Autor

SOA simplifica la integracin de sistemas heterogneos, sistemas que requieren gran conectividad
e integracin de diversos dispositivos, procesos, formatos, plataformas, bases de datos, etc.,
aumentando la reutilizacin de software, haciendo que muchas de las aplicaciones migren a SOA
en la actualidad. Las ventajas de adoptar SOA son muchas, pero tambin esta arquitectura no se
acopla a todo tipo de aplicaciones y para efectuar algn cambio en stas se debe tener en cuenta
el impacto que puede tener en la implementacin.

37

1.5.5.

Elementos de SOA.

Para implementar una arquitectura orientada a servicios se lo debe hacer en base a estndares
que definen el manejo de aplicaciones, la comunicacin entre los servicios, SOA posee los
siguientes elementos, como se muestra en la Figura 10:

Elementos
SOA

Aplicacin

Contrato

Repositorio de
Serv icios

Serv icios

Implementacin

Lgica de
Negocio

Bus de
Serv icio

Interfz

Datos

Figura 10. Elementos de SOA.


Fuente: (Gonzles Quiroga, 2011)
Elaboracin: Autor

Aplicacin.- Son aquella que descubren los servicios a travs de un repositorio, y


pueden acceder a los servicios mediante llamadas a su interfaz.

Servicio.- En el servicio es donde se encuentra la lgica del negocio, es un elemento


con funcionalidad reutilizable, y est compuesto por:

Contrato.- Detalla la funcionalidad, uso y restricciones del servicio.

Interfaz.- Mecanismo de exposicin de servicios.

Implementacin.- Debe contener la lgica o al acceso a datos.

Repositorio de Servicios.- Provee de la facilidad de describir y ubicar la ubicacin de


los servicios web, suministrando informacin del contrato, restricciones y acuerdos del
servicio.

Bus de servicios.- Enterprise Service Bus o ESB, es el encargado de conectar a todos


los componentes, es una infraestructura basada en estndares, es un middleware de
intermediacin a travs de la cual se puede acceder a un conjunto de servicios de
negocios reutilizables. Es el elemento fundamental para la implementacin de SOA, la
interaccin del ESB con los servicios web.

38

Para la parte de implementacin del presente trabajo se desarrollar la parte de los elementos de:
servicio y la aplicacin consumidora del mismo, para demostrar lo concerniente a la seguridad
para evitar las vulnerabilidades de SQL Injection, XSS y exposicin de datos sensibles, utilizando
los estndares del WS-Security.
1.5.6.

Capas de la arquitectura SOA.

La implementacin de una arquitectura orientada a servicios debe realizar por niveles y de forma
progresiva. En la Figura 11 se puede observar las capas de una arquitectura orientada a servicios:

Capa de Servicios.- Los servicios son los elementos bsicos de SOA. Existen dos
formas para crear un servicio:
o

Top-Down.- Primero se identifica y se describe las operaciones que el servicio


deba ofrecer y luego si se lo implementa, es decir escribir el cdigo y luego se
genera el archivo WSDL. Es recomendable utilizar esta forma cuando se va
crear un servicio completamente nuevo.

Bottom-Up.- Mediante esta forma se puede reutilizar componentes de negocio


existentes, es decir crear un servicio a partir de un archivo WSDL.

Capa de Procesos de Negocio.- SOA permite la orquestacin o estandarizacin del


modelado de los procesos de negocio, es decir se puede crear una capa de servicios
basada en la abstraccin de sistemas existentes antiguos.

Capa de Presentacin.- Esta capa representa la vista que puede tener el usuario, por
ende es muy importante. Se puede hacer si hablamos de tecnologas Java con: JSP,
JSF, portlets, servlets o clientes Java independientes.

Capa de Presentacin

JSP

Controlador

JSF

Vista

Capa de Negocio

Capa de Serv icio

Enlace de Datos

Componentes
de Negocio

Interfaz (WSDL)

EJB

Capa de
Procesos

Figura 11. Capas de SOA.


Fuente: (Enriquez Huaca & Caraguay, 2011)
Elaboracin: Autor

39

Componentes
de Negocio

Clase Jav a

Capa de
Persistencia

1.5.7.

Funcionamiento de SOA.

Para Cervantes (2010) la implementacin de los procesos como servicios es la clave de la


flexibilidad de la arquitectura, permitiendo la reutilizacin de los servicios de forma natural e
independiente de su ubicacin por parte de otros componentes.
La secuencia de ejecucin del funcionamiento bsica se inicia cuando el proveedor de servicio da
de alta al servicio web en el registro (UDDI), para esto el proveedor almacena en el registro el
documento de descripcin de ste (WSDL). El solicitante del servicio busca en el registro un
servicio web que pueda adaptarse a sus necesidades. Ya identificado el servicio til a la necesidad,
se selecciona el servicio, el solicitante lo invoca mediante el envo de mensajes SOAP, en el cual
se indica la accin a realizar y los datos de entrada. Finalmente el servicio web recibe la peticin y
ejecuta la funcionalidad, enviando los resultados obtenidos mediante un mensaje SOAP, como se
puede ver en la Figura 12:

Registro del
Serv icio

1. Publicar

2. Descubrir

Consumidor del
Serv icio

Prov eedor del


Serv icio

3. Conectar
WSDL

Mensaje
SOAP

4. Invocar

Direccin URI

Figura 12. Ciclo de funcionamiento de los servicios web SOA


Fuente: (Iturricha. Ibai & Urkizu, 2010)
Elaboracin: Autor

Para la implementacin de aplicaciones complejas, es conveniente desarrollar componentes ms


pequeos como los servicios que se los puedan reutilizar y probar; esta es la arquitectura orientada
a servicios, cuyo requerimiento es tener una comunicacin escalable y segura entre los
componentes, este requerimiento lo provee el ESB que es el eje principal del sistema.
Hay que hacer una aclaracin muy importante que no siempre una arquitectura SOA se
implementar con servicios web, se puede tener SOA sin servicios web y viceversa, pero lo ideal

40

es que es que siempre vayan de la mano estas tecnologas, ya que los estndares de los servicios
web forman una base para la implementacin de SOA.
Para la implementacin de SOA, en la organizacin se produce una transformacin, porque no
solo es el cambio tecnolgico, sino que cambia tambin la forma de dirigir y gestionar la empresa,
y se lo debe modelar de acuerdo a cada organizacin.
En la Tabla 6 se muestra los mitos y las realidades que existen en la Arquitectura Orientada a
Servicios.
Tabla 6. Mitos y realidades sobre SOA.
MITO

REALIDAD

SOA es una tecnologa

SOA es una filosofa de diseo independiente de


cualquier proveedor, producto, tecnologa o industria.
Las necesidades de SOA varan de una compaa a
otra, por tanto la adquisicin de una arquitectura SOA de
otra compaa no ser la solucin apropiada para su
propia compaa

SOA requieren de servicios web

SOA se puede realizar a travs de servicios web pero


los servicios web no son un requisito necesario para
implementar SOA

SOA es nuevo y revolucionario

EDI, CORBA y DCOM son ejemplos conceptuales de


orientacin de servicios

SOA garantiza la alineacin de TI y el negocio

SOA no es una metodologa

Una arquitectura de referencia SOA reduce


riesgo de implementacin

No hay dos SOA iguales. Una arquitectura de referencia


SOA puede no ofrecer la mejor solucin para su
organizacin

SOA requiere una revisin completa de la


tecnologa y procesos de negocios

SOA debe ser gradual y construirse sobre sus


inversiones actuales

Necesitamos construir una SOA

SOA es un medio, no un fin

Fuente: (Microsoft Developer Network Chapter 1: Service Oriented Architecture (SOA), 2014)
Elaboracin: Autor

1.6. Vulnerabilidades
1.6.1.

Definicin

Para Crespo Crespo, Augusta & Ramos Choes (2012) una vulnerabilidad o fallo es la posibilidad
de que una amenaza se materialice sobre un activo, un activo es un recurso de un sistema de

41

informacin o relacionado con ste, necesario para que la organizacin funcione correctamente,
incluye tanto elementos fsicos como abstractos. As mismo define que la amenaza es un evento
que puede producir daos tangibles o intangibles, incidiendo en la organizacin.
Segn Defaz Toapanta, (2006) vulnerabilidad es el punto o aspecto del sistema que es susceptible
de ser atacado o de daar la seguridad del mismo, es decir son la debilidades o aspectos que son
atacables en el sistema informtico.
Andrade, Jimenez, & Valencia (2013) define a la Vulnerabilidad como la capacidad, las condiciones
y caractersticas del sistema mismo (incluyendo la entidad que lo maneja), que lo hace susceptible
a amenazas, con el resultado de sufrir algn dao. En otras palabras, es la capacitad y posibilidad
de un sistema de responder o reaccionar a una amenaza o de recuperarse de un dao.
Se concluye que vulnerabilidad se refiere a la exposicin que tiene la infraestructura a los diferentes
riesgos. La vulnerabilidad provoca que los sistemas informticos funcionen de manera irregular o
diferente para lo que estaban diseados, afectando la seguridad de los mismos. Si existe algn
agujero de seguridad y mientras sta permanezca abierta se est expuesto a que cualquier ataque
se efecte. En trminos informticos vulnerabilidad es un punto del sistema que es susceptible a
ser atacado o daado.
1.6.2.

Tipos de vulnerabilidades

Las vulnerabilidades como se mencion anteriormente pueden ser tangibles e intangibles; aunque
no existe una clasificacin definida de vulnerabilidades ya que se lo puede tomar desde varios
enfoques, pero se tomar la clasificacin que hace Defaz Toapanta (2006) en 3 grupos:

Vulnerabilidad Fsica.- Se refiere al grado en que el sistema puede verse afectado por
desastres naturales o ambientales que pueden daar el sistema, como el fuego,
inundaciones, rayos, terremotos, o quizs ms comnmente, fallos elctricos o picos de
potencia. Otro aspecto es la posibilidad de entrar o acceder fsicamente al sistema para
robar o daar los discos, cintas, listados de impresora, etc. Ejemplos:
o

Acceso no protegido a las instalaciones informticas.

Construccin deficiente de edificios.

Materiales inflamables empleados en la construccin.

Puertas y ventanas sin cerrojo.

Paredes que se pueden asaltar fsicamente.

42

Paredes interiores que no sellan la sala por completo tanto en el techo como en
el suelo.

Instalacin situada sobre una lnea de error.

Instalacin situada en una zona de inundaciones.

Instalacin situada en un rea de avalanchas.

Vulnerabilidad Lgica.- La falta de seguridad y puntos dbiles de las aplicaciones


utilizadas por la organizacin que permitan el ingreso de personas no autorizadas a los
activos. Aumenta enormemente la escala del riesgo al que est sometido, al aumentar
la cantidad de gente que puede tener acceso al mismo o intentar tenerlo. Tambin se
aade a este riesgo de intercepcin de las comunicaciones: donde se puede introducir
al sistema a travs de la red, interceptando la informacin que es transmitida desde o
hacia el sistema. Desde el punto de vista del hardware, ciertos tipos de dispositivos
pueden ser ms vulnerables que otros, algunos sistemas requieren la posesin de algn
tipo de herramienta o tarjeta para poder acceder a los mismos. Por ejemplo:

Software antivirus obsoleto.

Aplicaciones escritas deficientemente.

Vulnerabilidades de cdigo como desbordamientos de bfer.

Programas espa como aplicaciones de captura de teclado.

Virus.

Errores de configuracin.

Sistemas no protegidos.

Carencia o insuficiencia de los mecanismos de identificacin y autenticacin.

Falta de sistemas de encriptacin de la informacin.

Vulnerabilidad Humana.- Las personas que administran y utilizan el sistema


representan la mayor vulnerabilidad, pueden ser voluntarias e involuntarias. Toda la
seguridad del sistema descansa sobre el administrador del mismo que tiene acceso al
mximo nivel y sin restricciones a estos recursos. Los usuarios del sistema tambin son
considerados como un gran riesgo, ellos pueden acceder al mismo, tanto fsicamente
como mediante conexin. Por ejemplo:
o

Falta de capacitacin al personal de la organizacin.

Falta de conciencia por parte del personal a nivel de seguridad.

Vandalismo y Estafas.

Invasiones.

Credenciales robadas.

43

No se puede decir que un sistema informtico es totalmente seguro, pero se puede crear
mecanismos que permitan evitar la mayora de ataques. El presente trabajo se centrar sobre las
vulnerabilidades de tipo lgicas, principalmente sobre las que pueden ocurrir durante el diseo y
codificacin de una aplicacin web. Los temas sobre este tipo de vulnerabilidades se revisarn en
el apartado denominado OWASP.
1.7. OWASP (The Open Web Application Security Project)
1.7.1.

Definicin

Salgado, Ron, & Solis (2014) menciona que The Open Web Application Security Project (OWASP)
como:
Un proyecto de cdigo abierto de seguridad en aplicaciones web y determina las causas
que hacen un software inseguro. Ofrece un Top 10 sobre los riesgos ms importantes en
aplicaciones web con el objetivo principal de educar a desarrolladores, diseadores,
arquitectos, gerentes y organizaciones.
OWASP es una comunidad abierta dedicada a habilitar a las organizaciones a desarrollar, comprar
y mantener aplicaciones en las que se pueda confiar. OWASP cuenta con aplicaciones libres,
herramientas de seguridad, recomendaciones, libros completos sobre pruebas de seguridad de
aplicaciones, cdigo de desarrollos seguros, investigacin de vanguardia, controles de seguridad
estndares, bibliotecas, etc., para el desarrollo de aplicaciones web seguras (OWASP, 2013).
Hermoso Metaute (2013) menciona que: OWASP es un organismo que est conformado por
empresas e instituciones acadmicas que contribuyen econmicamente y acadmicamente en los
distintos proyectos que promueve. Algunos de los principales proyectos de OWASP son:

OWASP Application Security Verification Standard (ASVS): Provee de una serie de


verificaciones y comprobaciones de alto nivel con la finalidad de clasificar la aplicacin web
segn a los cuatro niveles de seguridad que reconoce.

OWASP Enterprise Security API (ESAPI): Es una librera que facilita a los programadores
la creacin de aplicaciones seguros, esta librera est disponible para varios lenguajes de
programacin.

OWASP Development Guide: Es un documento con consejos y buenas prcticas que


guan a los programadores para desarrollar software seguro, est disponible para varios
lenguajes de programacin.

44

OWASP Top 10: Listado de las 10 vulnerabilidades ms crticas

presentes en las

aplicaciones web, esta lista se actualiza cada 3 aos aproximadamente por la organizacin.

OWASP Testing Guide: Es una gua que contiene un conjunto de tcnicas y mtodos
para encontrar las vulnerabilidades ms comunes en las aplicaciones web.

OWASP Zed Attack Proxy (ZAP): Es una herramienta potente para el escaneo de
vulnerabilidades en las aplicaciones web.

Todas las herramientas de OWASP son gratuitas, y disponibles para utilizar por cualquiera que
quiera proveer de seguridad a sus aplicaciones; ya que es una organizacin sin fines de lucro,
todos sus asociados son voluntarios, que apoyan la investigacin innovadora sobre seguridad;
busca la creacin de conciencia acerca de la seguridad en aplicaciones mediante la identificacin
de algunas vulnerabilidades que presentan las organizaciones en sus aplicativos, enumerados en
el OWASP Top Ten.
1.7.2.

OWASP Top Ten

El Top ten es uno de los proyectos ms importantes y conocidos de OWASP para dar seguridad a
las aplicaciones, OWASP Top Ten se centra en la identificacin de los riesgos ms crticos que
pueden ocurrir en las aplicaciones web. El objetivo principal del Top Ten es formar a los
desarrolladores, diseadores, arquitectos, gerentes y organizaciones, sobre las consecuencias de
las vulnerabilidades de seguridad ms importantes .Estos 10 tipos de vulnerabilidades son las ms
crticas no las ms comunes, y se actualiza cada 3 aos, siendo la primera versin en el ao 2003
y la ltima versin la del 2013, listada a continuacin por OWASP (2013):

Inyeccin

Prdida de autenticacin y gestin de sesiones

Secuencia de comandos en Sitios Cruzados (XSS)

Referencia directa insegura a objetos

Configuracin de seguridad incorrecta

Exposicin de datos sensibles

Ausencia de control de acceso a funciones

Falsificacin de peticiones en sitios cruzados (CSRF)

Utilizacin de componentes con vulnerabilidades conocidas

Redirecciones y reenvos no vlidos

45

Para el presente estudio se identific 3 tipos de vulnerabilidades con el objetivo de implementar


tcnicas para su mitigacin en un prototipo; stas corresponden a la primera, tercera y sexta
vulnerabilidad del listado anterior, las cuales han sido seleccionadas como las 3 principales
vulnerabilidades ms comunes y de acuerdo a su en los servicios web, descritas a continuacin:

SQL Injection.- La vulnerabilidad de SQL Injection ocurre cuando no existe una correcta
validacin de los datos de entrada y stos contienen sentencias SQL, estas sentencias
contienen cdigos maliciosos en los formularios web o URL en las que rdenes SQL son
inyectados en texto para afectar la normal ejecucin de una consulta SQL predefinida, con
el propsito de atacar a los servidores de base de datos y poder acceder a datos sensibles
de la base de datos. En la Figura 13 se presenta los detalles de esta vulnerabilidad:

Figura 13. SQL Injection


Fuente: (OWASP, 2013)
Elaboracin: OWASP

En la Figura 14 se muestra un ejemplo de una sentencia SQL normal, y en la Figura 15 se muestra


un ejemplo de cmo construir un ataque de inyeccin SQL bsico:
0
SELECT * FROM

1
tabla

2
WHERE

3
atributo=

Figura 14. Ejemplo de sentencia SQL


Fuente: (Guamn Quinche, n.d.)
Elaboracin: Autor

46

4
entrada de usuario

SELECT * FROM

tabla

2
WHERE

3
atributo=

entrada de usuario

OR

6
1

Figura 15. Ejemplo de SQL Injection


Fuente: (Guamn Quinche, n.d.)
Elaboracin: Autor

Para prevenir este tipo de ataque OWASP recomienda: usar APIs seguras que no permitan la
ejecucin del intrprete de base de datos, usar procedimientos almacenados, validar y limpiar todo
dato de entrada que el usuario ingrese en la URL.

Cross Site Scripting.- Este tipo de vulnerabilidad XSS o secuencia de comandos en sitios
cruzados sucede cuando por falta de mecanismos de filtrado de los datos de entrada, el
atacante puede insertar cdigo malicioso en forma de cdigo JavaScript o Visual Basic
Scripts. A travs de un ataque XSS se puede secuestrar cuentas, cambiar configuraciones,
acceder a partes restringidas de la pgina, modificar el contenido de la pgina, entre otras
cosas. Estos scripts pueden ser introducidos mediante:
o

Inyeccin de scripts en un formulario que luego es enviado al servidor donde el


script es introducido en el cdigo fuente donde se ejecutara cada vez que se cargue
la pgina.

Inyeccin por medio de la URL o de los elementos que viaje entre el navegador y
la aplicacin como atributos de las etiquetas HTML de la pgina.

Inyeccin por medio de recursos, por medio de las cabeceras HTTP, que son
mensajes con los que se comunican el servidor y el navegador.

Un ataque XSS se puede detectar mediante la insercin de cdigo JavaScript en formularios o en


la misma URL, la Figura 16 de detalla esta vulnerabilidad:

47

Figura 16. Secuencia de comandos en sitios cruzados


Fuente: (OWASP, 2013)
Elaboracin: OWASP

OWASP hace las siguientes recomendaciones para evitar el ataque de XSS: validar la longitud,
formato y caracteres de los datos, limpieza de los datos de entrada, aplicacin de polticas de
seguridad.

Exposicin de Datos Sensibles.- Los datos o informacin son el recurso ms importante


de toda empresa, ya que sin ellos simplemente no podran existir procesos; es por eso que
se debe proteger los datos que transitan por una aplicacin web, en especial se debe cuidar
aquella informacin sensible como informacin personal, contraseas, nombres de
usuarios, nmeros de tarjetas de crdito, etc., que son muy susceptibles a que una personal
no autorizada tenga acceso a stos. En la Figura 17 se identifica los vectores de ataque y
su impacto:

48

Figura 17. Exposicin de datos sensibles.


Fuente: (OWASP, 2013)
Elaboracin: OWASP

Por tal razn, como recomienda OWASP, es conveniente la utilizacin de algoritmos fuertes de
cifrado, no almacenar datos sensibles innecesarios, deshabilitar el autocompletar de los
formularios, as como tambin el uso de un canal seguro de comunicacin como por ejemplo a
travs de SSL o TSL.

49

CAPTULO II

PROPUESTA DE SOLUCIN

50

Tomando como base las referencias tericas expuestas anteriormente, donde se consideran
aspectos relacionados con la construccin de servicios web seguros, el prototipo que se
implementar se lo pretende utilizar para la consulta de informacin correspondiente a los Temas
de Proyectos de Fin de Titulacin de la Universidad Tcnica Particular de Loja. La solucin estar
enfocada en la implementacin de aspectos de seguridad utilizando el estndar WS-Security,
recomendaciones OWASP para evitar vulnerabilidades de tipo SQL Injection, XSS y exposicin de
datos sensibles; con la implementacin del prototipo se pretende validar si se cumplen aspectos
como integridad, confidencialidad y disponibilidad de la informacin.
2.1. Identificacin de vulnerabilidades
Una arquitectura orientada a servicios permite a los desarrolladores mucha flexibilidad, debido a
que la mayora de sus componentes estn expuestos como servicios, permitiendo de esta forma
accesibilidad y promoviendo la reutilizacin de software. Muchas son las empresas en utilizar SOA,
sin embargo algunos equipos de desarrollo no garantizan la calidad y la seguridad con la que estn
construidos los servicios web. Problemas de diseo, de codificacin, de configuracin suelen
representar riesgos crticos o vulnerabilidades en los servicios web.

Muchas son las

vulnerabilidades a las que un servicio web est expuesto, entre las ms comunes mencionadas
por National Security Agency (n.d.) tenemos:

Inyecciones.- Cuando no se valida correctamente las entradas, stas pueden ser


maliciosas haciendo que el software sea inseguro; tipos de inyecciones pueden ser como:
inyecciones SQL y cross site scripting (XSS).

Comunicaciones inseguras.- Durante el transporte de la informacin los atacantes pueden


extraer o modificar los datos si no se protege mediante mecanismos como TSL o SSL para
proteger el contenidos de los mensajes que contengan informacin sensible de los
usuarios.

Problemas de Autenticacin.- As mismo las comunicaciones inseguras pueden ocurrir por


falta de mtodos de autenticacin entre el cliente y el servidor, por tal razn es necesario
la implementacin de mecanismos de autenticacin tales como SAML en los mensajes
SOAP para proteger la informacin crtica.

Para evitar alguna infiltracin o vulnerabilidad a las aplicaciones web, se debe iniciar con el diseo
de una arquitectura donde se contemplen aspectos relacionados tanto a la funcionalidad y la
seguridad del sistema que se implementar, tomando en cuenta la utilizacin de patrones de
diseo arquitectnico, estndares y recomendaciones de buenas prcticas.

51

A continuacin se detalla los patrones que se utilizar para la implementacin del prototipo:
2.2. Patrn arquitectnico
Modelo Vista Controlador.- El patrn arquitectnico MVC resuelve el problema de reusabilidad
desacoplando las capas de vista, modelo y de datos, permitiendo hacer cualquier modificacin en
cualquiera de las capas impactando en menor medida al resto de capas. El MVC se basa en la
reutilizacin de cdigo y la separacin de conceptos. Se propone utilizar MVC debido a que permite
la reutilizacin y el desacoplamiento de cdigo, principios de la orientacin a servicios; adems
permite la implementacin de la aplicacin mediante mdulos claramente identificados y
separando la capa de persistencia, la lgica de negocio y la presentacin en la aplicacin.
2.3. Patrones de diseo
Facade.- El patrn estructural Fachada (en espaol), sirve para simplificar la comunicacin entre
dos objetos mediante la utilizacin de una interfaz que hace de puente entre el cliente y una interfaz
sencilla y sta se conecta con otras interfaces ms complejas. En el presente prototipo se utiliza
el patrn Facade para:

Proporcionar una interfaz sencilla ante el cliente, ocultando al cliente los componentes de
los subsistemas.

Hacer que el cdigo sea reutilizable.

Hacer que la codificacin est bien estructurada.

Personalizar cada subclase de acuerdo a los requerimientos.

Data Access Object (DAO).- Oracle (n.d.) menciona que el patrn de diseo Core JavaEE
conocido como DAO se utiliza para abstraer y encapsular todo el acceso a la fuente de datos. El
DAO gestiona la conexin con la base de datos para obtener y almacenar datos. Es decir que este
patrn sabe que fuente de datos es (ya sea una base de datos, un archivo plano, archivo XML,
etc.) ocultando para la aplicacin los detalles de acceso a los datos, bajando el nivel de
acoplamiento entre las clases.
DAO acta como intermediario entre la aplicacin y la base de datos por medio de una API. Esta
API generalmente consiste en mtodos CRUD (Create, Read, Update, Delete), en nuestro caso
utilizaremos Java Persistence Api (JPA), para acceder a los datos:

Java Persistence Api.- Este api ms conocido como JPA es una especificacin que posee
varias implementaciones como Hibernate, ObjectDB, EclipseLink, Apache OpenJPA, etc.

52

Se utiliza JPA para el Mapeo Objeto-Relacional (ORM), es decir para la asignacin o


mapeo de tablas de la base de datos a de objetos Java y viceversa. El mapeo se realiza
mediante metadatos de persistencia, definidas en clases java.
Para la implementacin del prototipo se utilizar DAO debido a que una de las caractersticas de
este patrn es que permite el bajo acoplamiento entre las clases, y ste es un principio de SOA; es
decir que las clases que contienen la lgica de negocio no tienen conocimiento de la fuente de
datos, reduciendo la complejidad para realizar cambios en la aplicacin.
2.4. Herramientas para el desarrollo del prototipo
Java.- Java es un lenguaje de programacin orientado a objetos, siendo uno de los lenguajes ms
populares y ms utilizados en todo el mundo, tanto en dispositivos mviles, aplicaciones web,
aplicaciones de escritorio, etc. Su principal caracterstica es que es un lenguaje independiente de
la plataforma, es decir que cualquier aplicacin desarrollada bajo la plataforma java puede
funcionar en cualquier computador indistintamente del sistema operativo, ya que utiliza la mquina
virtual de java que hace de puente entre la aplicacin y el sistema operativo. Posee varias ventajas
como: Independencia de plataforma, alto rendimiento, fcil de aprender, seguridad, flexibilidad,
expandible y es de cdigo libre.
Para el presente proyecto se utilizar Java EE en su versin 7, ya que cuenta con un conjunto de
API y servicios para trabajar con aplicaciones web distribuidas multicapas, separando la capa de
presentacin, la del modelo y la de acceso a datos, basado en el patrn MVC.
Glassfish.- Glassfish es un servidor de aplicaciones de cdigo libre que implementa las
tecnologas especificadas por Java EE que soporta las ltimas versiones de tecnologas como JSP,
JSF, Servlet, EJB, Persistencia Java, JAX-WS, etc. ste ltimo utilizado para la implementacin de
nuestros servicios web SOAP, siendo una buena solucin empresarial que son porttiles y
escalables. Las ltimas versiones de Glassfish tiene como caractersticas principales: modular,
integrable y extensible.
Cabe recalcar que Glassfish es una implementacin de JAVA EE y adems posee soporte para
Metro, JAX-WS y WSIT, tecnologas elegidas para la implementacin de seguridad en los servicios
web, estas tecnologas se detallarn ms adelante.
MySQL.- My Structured Query Language, es un sistema de base de datos relacional, este motor
de base de datos fue seleccionado ya que es un software de cdigo abierto por ende muy popular
y el ms utilizado en la actualidad gracias a su velocidad, rendimiento, robustez, soporta gran
53

cantidad de datos, facilidad de uso y portabilidad para trabajar en distintas plataformas y sistemas
operativos. Dentro de las ventajas para utilizar este motor de base de datos se pueden citar las
siguientes:

Velocidad para realizar transacciones, siendo el de mejor rendimiento.

Facilidad de instalacin y configuracin.

Gracias a su conectividad y seguridad hacen que su uso sea fiable en la web.

Soporta funciones y procedimientos almacenados.

Seguridad en cuantos a permisos y privilegios.

Metro.- Es un framework para el desarrollo de servicios web de alto rendimiento, extensible y fcil
de usar, es parte o est incluido dentro del servidor de aplicaciones Glassfish a partir de su versin
2, aunque tambin est dentro de JBoss, Oracle WebLogic Server, pero puede ser utilizado
tambin fuera de l. Este Metro es una coleccin de tecnologas tales como: JAX-WS, JAXB y
WSIT, para la implementacin y la interoperabilidad de servicios web. Metro permite utilizar HTTP
a nivel de transporte, adems la fiabilidad de mensajes (Reliability) mediante la implementacin de
especificaciones de WS-Security.
Los componentes principales de Metro son 2: JAX-WS RI y WSIT. Tecnologas que describiremos
a continuacin:
JAX-WS.- Es un API usado para la implementacin de servicios web XML, JAX-WS promueve la
interoperabilidad SOAP, es parte de la plataforma Java EE y de la distribucin de Metro descrita
anteriormente, y es open source, Usa Java Architecture XML Binding (JAXB) para acceder
procesar los documentos XML desde una aplicacin java sin tener que ser experto en
procesamiento XML.
JAX-WS permite desarrollar servicios web que se comunican a travs de XML, utilizando mensajes
orientados a llamadas a procedimientos remotos (RPC) representado en el protocolo SOAP, ste
protocolo define la estructura y la codificacin de las llamadas y respuestas de los mensajes a
travs de HTTP. Por eso una de las razones por la cual se utilizar este API es porque ayuda a
ocultar la complejidad de los mensajes SOAP, incluyendo todas las funcionalidades de los
mensajes SOAP como WS-Addressing.
WSIT.- Web Services Interoperability Technologies (WSIT), anteriormente conocido como
Proyecto Tango, es una tecnologa de la pila de Metro, encargada de la interoperabilidad de
servicios web, siendo la interoperabilidad la base principal de la orientacin a servicios incluido en

54

este estudio. La seguridad soportada por WSIT es una implementacin de OASIS WS-Security,
WS-Trust, WS- Secure Conversation, WS-Security Policy, que proveen un framework para
asegurar el intercambio de mensajes SOAP garantizando la interoperabilidad, integridad y la
confidencialidad del contenido de los mensajes. WSIT se compone de una serie de Apis de Java
y extensiones para el protocolo SOAP que permiten implementar caractersticas WSInteroperability (WS-I) como se puede ver en la Figura 18:

Core XML
XML

Optimization

XML Namespace

Reliability

SOAP

XML Infoset

WS-ReliableMessaging

MTOM

XML Schema

WS-Coordination

WS-Addressing
WS-Atomic Transaction

Bootstraping

WSDL

Seguridad
WS-Security Policy
WS-Security

WS-Policy
WS-Trust
WS-MetadataExchange
WS-SecureConv ersation

Figura 18. Componentes WSIT


Fuente: (Patio Castillo, 2014)
Elaboracin: (Patio Castillo, 2014)

Netbeans IDE conjuntamente con WSIT provee de mecanismos de seguridad implementados por
WSIT para configuracin tanto en el servicio como en el cliente, Estos mecanismo son:

Username Authentication with Symmetric Keys (UA)

Mutual Certificates Security (MCS)

Transport Security (SSL)

SAML Authorization over SSL (SA)

SAML Sender Vouches with Certificates (SV)

STS Issued Token (STS)

55

El presente trabajo est enfocado a la seguridad de los servicios web, por tal razn nos referiremos
a la parte de seguridad, optimizacin de mensajes y a la mensajera fiable utilizando: SOAP,
WSDL, WS-Security Policy y WS-Security, y como mecanismos de autenticacin: SAML Sender
Vouches with Certificates, descritos a continuacin:
2.5. Identificacin de protocolos y estndares de seguridad
SOAP.- Simple Object Access Protocol (SOAP), es un protocolo estndar para el intercambio de
informacin estructurada por medio de XML, siendo de fcil entendimiento para el ser humano. Lo
mensajes SOAP se transportan encapsulados por medio de otros protocolos como SMTP, HTTP,
etc. Los mensajes tanto de peticin 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 informacin 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 informacin entre el remitente y destinatario del mensaje SOAP.

La utilizacin de SOAP tiene como ventajas el no estar asociado a ningn lenguaje ni a ningn
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 ests sin seguridades.

56

Figura 19. Ejemplo de SOAP Request y SOAP Response


Fuente: Autor
Elaboracin: Autor

WSDL.- Web Services Description Language (WSDL), es el lenguaje de descripcin de servicios


web, su ubicacin, sus operaciones, argumentos, protocolos de comunicacin y cmo acceder al
servicio en la red. El WSDL es un documento XML con el cual una aplicacin 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 (Ordez Len, 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 informacin necesaria de los mensajes para realizar una
operacin de entrada y salida. Cada mensaje est compuesto por partes y cada parte tiene
su nombre y su tipo de datos definidos anteriormente.

Operacin <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 operacin. Un tipo de puerto es una agrupacin lgica de
operaciones relacionadas entre s.
57

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 conexin del servicio (URI) donde se
puede acceder al servicio.

Servicio <service>.- Un servicio define un tipo de puerto con un Binding a travs de una
direccin. Define los puntos o puertos finales de los bindings.

Serv ice

Port

PortType

Binding

Operation

Message

Figura 20. Estructura de documento WSDL


Fuente: (McDonald, 2009)
Elaboracin: Autor

WS-Security.- La especificacin WS-Security emitida por OASIS provee de un conjunto de


estndares para la mensajera SOAP para la construccin de servicios web seguros, garantizando
la confidencialidad e integridad de los datos y la autenticacin de los mensajes. Integra tecnologas
como PKI, SAML, XML Signature y XML Encryption, asegurando la interoperabilidad en cualquier
plataforma.
Cabe recalcar que la implementacin de WS-Security tiene como efecto una sobrecarga en el
rendimiento y desempeo debido a la sobrecarga de los mensajes, al aumento de su tamao
requieren de mayor memoria, de procesamiento ms rpido y de mayor ancho de banda. Pero
todos estos costes se justifican cuando se requiere de una aplicacin segura.
WS-Security provee un modelo unificado de cmo utilizar mecanismo de seguridad existente para
autenticacin, confidencialidad e integridad de los servicios web, para nuestro estudio utilizaremos
SAML para la autenticacin de los clientes que acceden al servicio web mediante certificados

58

X.509, que se describir ms adelante. En la Figura 21 podemos observar cmo es el flujo de


mensajes mediante WS-Security.
Enviar peticin de tokens
Cliente Web Serv ice

Security Token
Serv ice
Recibir Tokens para
aadir al mensaje
SOAP

Validar tokens

Firmar y enviar mensaje


Web Serv ice
Respuesta

Figura 21. Flujo de mensajes mediante WS-Security


Fuente: (Senmart, 2010)
Elaboracin: (Senmart, 2010)

Donde el cliente enva una peticin solicitando los tokens necesarios para la seguridad en la
comunicacin; el Security Token Service valida estas peticiones enviadas al web service
mediante Kerberos o certificados X.509 y aade 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 informacin
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 tecnologas que se implementan en SOAP. Este
estndar toma en cuenta las siguientes consideraciones (Ordez Len, 2010):

Identificacin y autenticacin de las partes.

Identificacin y autenticacin de los datos de origen.

Integridad de los datos.

Confidencialidad de los datos.

Unicidad de los datos.

SAML.- Security Assertions Markup Language (SAML) especificacin definida por OASIS, define
un esquema para XML para el intercambio de informacin que permite la autenticacin 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 autenticacin SAML en
sus aplicaciones como Gmail o Google Calendar.

59

En la Figura 22 se puede observar el proceso de funcionamiento de la autenticacin mediante


SAML:

Nav egador

Prov eedor del


Serv icio

Prov eedor de
Identidad

Get Recurso

Redirecciona al Id Proveedor
2

Get SAML peticin de autenticacin

Autenticacin de usuario
4
Pgina HTML peticin de autenticacin
5
Post SAML respuesta de autenticacin
6
Recurso
7

Figura 22. Autenticacin SAML


Fuente: (Jitta, 2012)
Elaboracin: Autor

Donde se el usuario a travs 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
peticin al proveedor de identidad, el cual solicita al usuario sus respectivas credenciales (tales
como usuario y contrasea), 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 especificacin para servicios web basada o derivada de WS-Policy,
proporciona una forma ms 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):

60

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
razn la mayora de los framework para servicios web integran una interfaz dinmicas para la
creacin de estos documentos; por ejemplo Metro es una herramienta que a travs de WSIT facilita
esta difcil tarea. La intencin de WS-Security Policy es proporcionar la suficiente informacin 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 construccin del servicio web:

Calidad
WS-Security
SAML

WS-SecurityPolicy

Ecriptacin

Firma Digital

Descripcin
WSDL

Mensaj era
SOAP

Transporte
HTTPS

Core XML
XML

Figura 23. Estndares de seguridad implementados en servicios SOAP


Fuente: Autor
Elaboracin: Autor

61

En la Tabla 7, se resume los patrones de diseo, protocolos, estndares de seguridad y


herramientas de desarrollo para el prototipo propuesto, as como una breve descripcin de los
mismos.
Tabla 7. Resumen de tecnologas utilizadas

COMPONENTE

NOMBRE

DESCRIPCIN
Estructurar la codificacin y ocultar la lgica de negocio de la
aplicacin para el cliente. Adems que permite la reutilizacin

Facade

y la fcil modificacin en el cdigo al momento de realizar


cambios.

Patrones

Gestionar la persistencia de los datos. Es la encargada de


interaccin con la base de datos, es decir controla el acceso a
DAO

la base de datos actuando de intermediario entre la base de


datos y la aplicacin.
Lenguaje de programacin multiplataforma ideal para
aplicaciones empresariales mediante JavaEE. Adems

Lenguaje
Programacin

de

Java 1.7

provee un aserie de APIs que facilitan de implementacin de


aplicaciones web.
Motor de base de datos gratuito, flexible, escalable y
multiplataforma, permite la creacin de procedimientos

Base de Datos

MySQL 5.0

almacenados y permite gestionar privilegios de usuarios para


evitar ataques SQL Injection.
Servidor de aplicaciones que soporta JavaEE, adems

Servidor de
Aplicaciones

permite la implementacin de servicios web SOAP mediante


Glassfish 4.1

su api JAX-WS.
Framework para la implementacin de servicios web SOAP,
contiene una pila de tecnologas y proyectos como JAX-WS y

Framework
Metro 2.3

WSIT que permiten la interoperabilidad y la implementacin


de servicios web seguros.
Estndar para implementar seguridad a servicios web SOAP,
provee un modelo unificado de cmo utilizar mecanismo de

Estndares de
Seguridad

WS-Security 1.0

seguridad para autenticacin, confidencialidad e integridad de


los datos de los servicios web

62

Especificacin basada en XML para el intercambio de


informacin

mediante

la

autenticacin,

asegurado

la

integridad y confidencialidad de los datos, mediante


SAML 2.0

aserciones integradas a travs del estndar WS-Security


Policy.
Afirmaciones de polticas de seguridad basadas en el marco
WS-Policy, donde se definen las polticas, las limitaciones y

WS-Security Policy
1.2

requerimientos de seguridad en el documento WSDL del


servicio web.
Protocolo de seguridad a nivel de transporte para aplicaciones
web, utiliza el cifrado basado en SSL creando un canal seguro

Transporte

HTTPS / SSL

por el cual transitan los datos.

Fuente: Autor
Elaboracin: Autor

63

CAPTULO III

DISEO DE LA SOLUCIN

64

En el presente captulo se expone el diseo 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 ms 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 WSSecurity, asegurando la comunicacin de origen a destino y no solo de punto a punto. Comparacin
que se menciona por Navarro Marset (2006),entre otras ms.
Con la finalidad de que la aplicacin web contenga una seguridad adecuada que implique
autenticacin, autorizacin de los servicios web, la encriptacin de los datos sensibles y la
prevencin de ataques de SQL injection y ataques XSS, se implementar diferentes mtodos,
estndares y especificaciones como: WS-Security, SSL descritas en captulos anteriores.
3.1 Diseo Arquitectnico de la aplicacin
El diseo de la aplicacin propuesta como solucin tiene 2 componentes: Aplicacin Cliente y
Servicio Web y. El componente de Aplicacin Cliente es quien consume las operaciones y mtodos
del servicio web mediante mecanismo de seguridad del WS-Security; el componente de Servicio
web contiene toda la lgica de negocio y el acceso a datos, representado mediante el WSDL, como
podemos observar en la Figura 24:

65

Glassfish (JAX-WS)

Web Serv ice


WSDL

WS-Security
Digital Certificates
HTTPS

SAML

Facade
Web
Serv ice

Business
Logic Serv ice

DAO
Persistence

Client App

SOAP

Encrypted Data

SOAP

JPA

JSON
Decrypted Data

MySQL (Store
Procedures)

Figura 24. Diseo arquitectnico de aplicacin SOA propuesta


Fuente: Autor
Elaboracin: Autor

A continuacin se describe cada uno de los componentes del diseo arquitectnico propuesto
anteriormente:
3.1.1. Web Service
La aplicacin de Servicio Web es donde se encuentran el acceso a los datos, la lgica de negocio
y lo concerniente a la seguridad, contiene los siguientes componentes:

Facade Web Service.- En esta capa es la encargada de implementar una fachada o interfaz
de la aplicacin, donde se invocaran los sub mtodos para acceder a los datos mediante
la capa de lgica de negocio.

Business Logic Service.- Es la capa encargada de proveer a la capa de Facade Servicio


Web de todos los mtodos que podr utilizar cuando los requiera.

DAO Persistence.-. Esta capa de persistencia es la que est encargada de gestionar el


acceso a los datos para la aplicacin. En nuestro caso utilizaremos JPA mediante la
implementacin EclipseLink. Esta capa contiene todo lo referente a la lgica de acceso a
los datos ya sea mediante consultas SQL o mediante procedimientos almacenados.

66

3.1.2. Client App


La aplicacin cliente es el usuario el cual va a consumir el servicio web a travs de un servlet en
un navegador web. Este cliente para poder comunicarse correctamente con la aplicacin del
servicio web deber cumplir con ciertos requisitos de seguridad como: el mecanismo de seguridad
mediante la autenticacin y autorizacin de SAML con certificados digitales, que permitir al cliente
poder acceder de forma satisfactoria al servicio web.
3.2. Diseo de base de datos
El modelo de base de datos utilizado est basada en informacin de los proyectos de fin de
titulacin de la Universidad Tcnica Particular de Loja. El modelo entidad relacin completo de la
base de datos utilizada se encuentra en el Anexo A. Cabe recalcar que se har uso de ciertas
tablas (Pft_Modalidades y Pft_Personas) del modelo total ya que solo ser realizar un pequeo
prototipo para demostrar que la aplicacin sea segura.
3.3. Diseo de Seguridad
Para la seguridad del presente proyecto se tom en cuenta las siguientes vulnerabilidades del Top
Ten de OWASP: SQL Injection, XSS y Exposicin de datos sensibles. Para los cuales se defini la
seguridad en tres aspectos: Codificacin, Configuracin y Base de datos, descritas a continuacin:
3.3.1. Codificacin
En la parte de codificacin para la seguridad del aplicativo web se tuvo en cuenta las tres
vulnerabilidades ya mencionadas.

SQL Injection.- Para evitar los ataques de SQL Injection implementar siguiendo las
recomendaciones de OWASP, el uso de procedimientos almacenados, que son programas
que estn alojados en la base de datos, los cuales trabajan directamente con el motor de
base de datos brindando mayor rapidez en el acceso a datos y evitando as la insercin
de sentencias SQL en la codificacin de la lgica de negocio. Adems se utilizar otra
recomendacin de OWASP como el de dar permisos y privilegios a usuarios de la base de
datos; en este caso como los servicios web solo harn consultas es decir recuperar
informacin, el usuario solo podr ejecutar llamadas a los procedimientos almacenados.
De este modo se puede asegurar la integridad de los datos.

XSS.- Los ataques de XSS se mitigarn con el uso de filtros, es decir una limpieza o
validacin de los datos de entrada ingresados por el usuario, ya que toda entrada de

67

usuario se puede definir como maliciosa, por tanto mediante un mtodo se limpia estos
parmetros de entradas a la aplicacin.

Exposicin de datos sensibles.- Siguiendo con las recomendaciones de OWASP para


proteger los datos sensibles se utilizar para como mtodo de proteccin el encriptado de
los datos devueltos de la consulta a la base de datos. El algoritmo utilizado es DES (Data
Encryption Standard), que es un algoritmo de encriptacin simtrico considerado dbil ante
otros tipos de algoritmos de cifrado, debido a su corta longitud de la clave. Pero se ha
escogido este algoritmo debido a que la aplicacin es un prototipo de prueba y DES es un
algoritmo bsico y fcil de implementar, ste algoritmo se lo puede reemplazar por
cualquier otro algoritmo mucha ms fuerte. Adems para proteger los datos sensibles se
utilizar otros mecanismo de seguridad como: SSL y el firmado y encriptado de datos
mediante el framework Metro con su implementacin de WSIT, que se detallar ms
adelante.
3.3.2. Configuracin

SAML Authorization Vouches with Certificates.- Este mecanismo de seguridad provisto por
WSIT protege los mensajes SOAP con certificados mutuos entre el cliente y servidor resguardando
la integridad y confidencialidad por medio de la autorizacin SAML. El remitente garantiza con
tokens la autorizacin para la comunicacin aadiendo las aserciones SAML en los mensajes
SOAP.
En este mecanismo, el token SAML se incluye como parte de la firma del mensaje como un token
de autorizacin y slo se enva al destinatario. La carga til del mensaje debe ser firmado y
cifrado. El solicitante est avalando las credenciales (presentes en la asercin SAML) de la entidad
en nombre de la cual el solicitante est actuando.
El token iniciador, que es un token de X.509, es utilizado para la firma. El token receptor, que
tambin es un token de X.509, se utiliza para el cifrado. Para el servidor, esto se invierte, el token
destinatario es la firma de contadores y el token iniciador es el token cifrado. Un token SAML se
utiliza para la autorizacin.
Para la correcta configuracin de este mecanismo en la Tabla 8 se exponen ciertos requerimientos
tanto en el servidor como en el cliente que deben cumplir.

68

Tabla 8. Requerimientos para configuracin de SAML Authorization Vouches with Certificates

Keystore

Truststore

SAML Callback Handler

Cliente

Si

Si

Si

Servidor

Si

Si

No

Fuente: Autor
Elaboracin: Autor

Keystore.- Este certificado proporciona las credenciales para el acceso.

Truststore.- Contiene el certificado de confianza del cliente y del servidor, verifica las
credenciales.

SAML Callback Handler.- Es una clase implementada en el cliente donde se especifica las
devoluciones a las llamadas del manejador de aserciones SAML.

HTTPS.- Hypertext Transfer Protocol Secure (HTTPS), es un protocolo de transporte seguro


recomendado por OWASP para la proteccin de informacin sensible que est expuesta entre el
paso de mensajes de las aplicaciones web, es un canal seguro por el cual se transmiten los datos
en una peticin y respuesta. HTTPS se basa en HTTPS para la transmisin de hipertexto, usa SSL
(Secure Sockets Layer) que permite crear un canal de cifrado que aumenta la seguridad en el
trfico de informacin. SSL proporciona autenticacin y privacidad de los datos de extremo a
extremo usando criptografa. Comnmente solo el servidor es autenticado, es decir garantiza su
identidad mientras que el cliente no.
La utilizacin de SSL para la proteccin de la informacin es una recomendacin de OWASP para
mantener a salvo de cualquier atacante que pueda intentar capturar los datos que se transmiten
en nuestra aplicacin, ya que existen herramientas con las que es posible detectar el trfico de la
red sin conexin SSL, por lo tanto terceras personas podrn conocer los datos que fluyan en
internet, como se demostrar ms adelante en el captulo de Pruebas.
Encriptacin y Firmado Digital con WSIT.- Adems del mecanismo de autenticacin SAML que
provee WSIT, tambin posee mecanismo de seguridad a nivel de operacin y de mensajes, donde se
especifica las partes del mensaje que requieren proteger la confidencialidad (cifrado) y la integridad
(firma digital); se puede configurar que solamente firme o encripte el cuerpo o body del mensaje y las
headers del mensaje. Se puede firmar y encriptar tanto los mensajes de entrada como los mensajes de
salida.

69

3.3.3. Base de datos


Con la finalidad de evitar ataques de SQL Injection se utilizar procedimientos almacenados, ya que
stos limitan los tipos de sentencias que se pueden insertar en una consulta maliciosa. Aunque a pesar
de que los procedimientos almacenados no es una tcnica 100% efectiva para evitar este tipo de
ataque, OWASP la recomienda conjuntamente con otras tcnicas como la de delimitar los privilegios de
usuarios de la base de datos, consultas parametrizadas y la filtracin de todo dato de entrada que el
usuario pueda introducir en la aplicacin web.
El uso de privilegios de usuarios de la base de datos ayuda a evitar los ataques de SQL Injection, pero
se puede tornar un poco tedioso asignar permisos especficos a cada usuario. En nuestro caso, como
la aplicacin solo requiere consultar informacin de la base de datos, se procedi a delimitar los
privilegios a solo ejecutar sentencias SQL de tipo SELECT y a la ejecucin de ciertos procedimientos
almacenados de la base pft_db.

70

CAPTULO IV

IMPLEMENTACIN DE LA SOLUCIN

71

El presente captulo expone el proceso para la implementacin de los servicios web utilizando el
estndar SOAP, se utiliz JEE7 para el desarrollo de la lgica de negocio o el Backend y el API
JAX-WS para la creacin de servicios web SOAP. En cuanto tiene que ver con las base de datos
se construy procedimientos almacenados en MySQL, para que sean consumidos por el backend.
As mismo, a nivel de seguridad de servicios web se implement el un mecanismo de seguridad
como es SAML, y para la proteccin de los datos se cifr utilizando el algoritmo DES y se firm la
informacin de los mensajes mediante la herramienta WSIT. Para detallar el desarrollo de los
servicios SOAP se consideran los siguientes niveles de implementacin:
4.1. Base de datos
La base de datos con la cual se despliegan el servicio web se denomina pft_db, la cual est
diseada en MySQL.
Se construyeron tres procedimientos almacenados, para que desde cualquier aplicacin estos
puedan ser consumidos; por lo tanto, la lgica de accedo a los datos se maneja en la capa de
datos. En el Anexo B se encuentra detallados los procedimientos almacenados construidos para
el prototipo.
En las Figura 25 se muestra la creacin del procedimiento almacenado para la consulta de todas
las personas en MySQL, y en la Figura 26 se ve cmo se implementa stos procedimientos en
Java. Se utiliz los procedimientos almacenados para evitar los ataques de SQL Injection
expuestos en el OWASP Top Ten.

Figura 25. Creacin de Procedimientos Almacenados en MySQL


Fuente: Autor
Elaboracin: Autor

72

Figura 26. Procedimientos Almacenados


Fuente: Autor
Elaboracin: Autor

4.2. Codificacin
El nombre del proyecto se denomina pft-ws, para el desarrollo de este proyecto se utilizaron las
siguientes dependencias. En la Tabla 9 se detallan las tecnologas utilizadas.
Tabla 9. Apis de java utilizadas en el proyecto

NOMBRE
org.glassfish.metro

VERSIN

DESCRIPCIN

2.3

Permite la implementacin de mecanismos de seguridad de


los servicios SOAP

gson
javaee-web-api

2.3.1
7.0

Se lo utiliz para devolver los objetos en formato JSON.


Java empresarial para la construccin de la lgica de negocio

eclipselink

2.5.2

Utilizado para la persistencia de los datos.

wsit

1.3.1

Tecnologa para proveer seguridad a los servicios SOAP.

Fuente: Autor
Elaboracin: Autor

En el archivo POM.xml (Project Object Model) de proyecto pft-ws se colocan las dependencias de
las APIs mencionadas en la tabla anterior de la siguiente manera (Figura 27):

73

Figura 27. Dependencias - Archivo POM.xml


Fuente: Autor
Elaboracin: Autor

Paquetes:
El proyecto de servicio web SOAP est conformado por los siguientes paquetes (Figura 28):

74

Figura 28. Diagrama de paquetes del proyecto pft-ws


Fuente: Autor
Elaboracin: Autor

Paquete Entity: Dentro de este paquete se encuentran los objetos de negocio, se utiliz JPA como
ORM para realizar el mapeo de las entidades de persistencia. Para la conexin del proyecto con
la base de datos existe un archivo denominado persistence.xml, es en este archivo donde se
configura la conexin. En la Figura 29 se indica la configuracin que permite mapear un objeto de
negocio con cada tabla de la base de datos pft_db:
Adems para el acceso a la base de datos se realiz una configuracin para la conexin con
MySQL, donde se especifica el nombre de la base de datos, el puerto, el usuario y claves de
acceso. El archivo que contiene estos datos se llama glassfish-resources.xml, como podemos
observar en la Figura 29:

75

Figura 29. Archivo glassfish-resources.xml


Fuente: Autor
Elaboracin: Autor

Paquete Dao: En este paquete se encuentra las clases que permiten realizar el acceso a datos,
se utiliz el patrn de diseo Data Abstract Object (DAO). En la Figura 30 se indica las clases que
conforman este paquete.

Figura 30. Paquete DAO


Fuente: Autor
Elaboracin: Autor

Con el patrn de diseo DAO podemos dividir las responsabilidades dentro de la aplicacin, en la
figura anterior podemos observar las clases encargadas en el acceso a datos la cual heredan los
mtodos y atributos de la clase AbstractDao, la clase AbstractDao es la encargada realizar las
operaciones CRUD de cualquier tipo de objeto debido a que recibe como parmetro un clase
genrica en su constructor.

76

Paquete Service: En este paquete contienen las clases que conforman la lgica de negocio de la
aplicacin. Se utiliz el patrn de diseo Facade, simplificando al mnimo la comunicacin entre
subsistemas. En la Figura 31 se indica las clase PftPersonaService que se encuentran dentro de
este paquete y cmo se comunican con las clases del acceso a datos.
interface
dao::PftPersonaDao
+
+
+
+
+
+
+
+
+

buscarPorCedula(String) : PftPersona
buscarTodo() : List<PftPersona>
count() : int
create(PftPersona) : void
edit(PftPersona) : void
find(Object) : PftPersona
findAll() : List<PftPersona>
findRange(int[]) : List<PftPersona>
remove(PftPersona) : void

AbstractDao
implement::PftPersonaDaoImplement
+
+
+

buscarPorCedula(String) : PftPersona
buscarTodo() : List<PftPersona>
PftPersonaDaoImplement()

-personaDao

implement::PftPersonaServ iceImplement
-

personaDao: PftPersonaDao

+
+

buscarPorCedula(String) : PftPersona
buscarTodo() : List<PftPersona>

interface
PftPersonaServ ice
+
+

buscarPorCedula(String) : PftPersona
buscarTodo() : List<PftPersona>

Figura 31. Clase PftPersonaService - Paquete Service


Fuente: Autor
Elaboracin: Autor

Por lo tanto se puede concluir que las clases que conforman el paquete DAO proveen una interfaz
a las clases del paquete Service para el acceso a datos, y que las clases del paquete Service
manejan la lgica de negocio para la gestin de los proyectos fin de carrera y proveen una interfaz
para los servicios web.
Paquete ws: Dentro de este paquete se encuentran una clase denominada PftWebService en
donde se encuentran los servicios web, para la construccin de los servicios web se utiliz JAXWS que permite construir servicio REST y SOAP, aunque la finalidad de este API son los servicios
SOAP. As mismo se encuentra una clase llamada Encripta, dentro de esta clase se tiene un
mtodo que permite encriptar y desencriptar un texto plano usando el algoritmo DES.
A continuacin se indica cada servicio construido.

77

Servicio getPersonas: Este mtodo devuelve todos los usuarios de la base de datos
pft_db, se utiliza un servicio EJB denominado personaService para manejar la lgica de
negocio para la obtencin de los datos (Figura 32).

Figura 32. Operacin getPersonas PftWebService


Fuente: Autor
Elaboracin: Autor

Servicio getModalidades: Este mtodo permite obtener todas las modalidades


almacenadas en la base de datos pft_db, se utiliza un servicio EJB denominado
pftModalidadService (Figura 33).

Figura 33. Operacin getModalidades PftWebService


Fuente: Autor
Elaboracin: Autor

Servicio personaPorCdula: Este mtodo permite obtener una persona cuyo nmero de
identificacin sea igual al enviado como parmetro (Figura 34).

78

Figura 34. Operacin personaPorCedula PftWebService


Fuente: Autor
Elaboracin: Autor

El api JAX-WS permite generar automticamente el archivo WSDL, donde se especifica los
puertos, las entradas y salidas de las operaciones que contiene el servicio web, sin seguridad. A
travs de este documento se puede acceder a las operaciones del servicio web mediante una
aplicacin cliente. En el Anexo C, se muestra el archivo generado del servicio web implementado:
Una vez desarrollado los servicios web, el siguiente paso es la configuracin de seguridad, que
permiten evadir las vulnerabilidades expuestas en OWASP.
4.3. Seguridad
4.3.1. Servicio Web
Configuracin SAML.- Para la confidencialidad y proteccin de los datos, se utiliz una
dependencia denominada webservices-rt que posee algunos mecanismos de seguridad, el
mecanismo de seguridad seleccionado es SAML Authorization Vouches with Certificates. En
el Anexo D, se indica los pasos para la configuracin de este mecanismo de seguridad en el
servicio web.
Una vez realizados los pasos del anexo D, el documento WSDL de anexo C se modifica
aadindose todas las aserciones y las polticas de seguridad, como se muestra a continuacin:
1.
2.

3.
4.
5.

6.

<!-Published by JAX-WS RI (http://jax-ws.java.net). RI's version is Metro/2.3.1-b419


(branches/2.3.1.x-7937; 2014-08-04T08:11:03+0000) JAXWS-RI/2.2.10-b140803.1500
JAXWS-API/2.2.11 JAXB-RI/2.2.10-b140802.1033 JAXB-API/2.2.12-b140109.1041 svnrevision#unknown.
-->
<!-Generated by JAX-WS RI (http://jax-ws.java.net). RI's version is Metro/2.3.1-b419
(branches/2.3.1.x-7937; 2014-08-04T08:11:03+0000) JAXWS-RI/2.2.10-b140803.1500
JAXWS-API/2.2.11 JAXB-RI/2.2.10-b140802.1033 JAXB-API/2.2.12-b140109.1041 svnrevision#unknown.
-->

79

7.

8.

9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.

<definitions xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd" xmlns:wsp="http://www.w3.org/ns/wspolicy"xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsam="http:


//www.w3.org/2007/05/addressing/metadata" xmlns:soap="http://schemas.xmlsoap.org/wsd
l/soap/"xmlns:tns="http://ws.wspft.utpl.edu/" xmlns:xsd="http://www.w3.org/2001/XMLS
chema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://ws.wspft.utp
l.edu/"name="PftWebService">
<wsp:Policy xmlns:sp="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702" xmlns:ssp="http://schemas.sun.com/2006/03/wss/server"xmlns:su
nwsp="http://java.sun.com/xml/ns/wsit/policy" wsu:Id="PftWebServicePortBindingPolicy
">
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:EncryptBeforeSigning/>
<sp:EncryptSignature/>
<sp:IncludeTimestamp/>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:RequireIssuerSerialReference/>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
<sp:OnlySignEntireHeadersAndBody/>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702/IncludeToken/Never">
<wsp:Policy>
<sp:RequireIssuerSerialReference/>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:SamlToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssSamlV20Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
<sp:Wss10>
<wsp:Policy>
<sp:MustSupportRefIssuerSerial/>
</wsp:Policy>
</sp:Wss10>
<wsam:Addressing/>
</wsp:Policy>
<wsp:Policy xmlns:sp="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702" wsu:Id="PftWebServicePortBinding_get_personas_Input_Policy">
<sp:EncryptedParts>

80

65.
66.
67.
68.
69.
70.
71.
72.

<sp:Body/>
</sp:EncryptedParts>
<sp:SignedEncryptedSupportingTokens/>
<sp:SignedParts>
<sp:Body/>
</sp:SignedParts>
</wsp:Policy>
<wsp:Policy xmlns:sp="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702" wsu:Id="PftWebServicePortBinding_get_personas_Output_Policy">
73. <sp:EncryptedParts>
74. <sp:Body/>
75. </sp:EncryptedParts>
76. <sp:SignedParts>
77. <sp:Body/>
78. </sp:SignedParts>
79. </wsp:Policy>
80. <types>
81. <xsd:schema>
82. <xsd:import namespace="http://ws.wspft.utpl.edu/" schemaLocation="https://localhost:
8181/pft-ws/PftWebService?xsd=1"/>
83. </xsd:schema>
84. </types>
85. <message name="get_persona_cedula">
86. <part name="parameters" element="tns:get_persona_cedula"/>
87. </message>
88. <message name="get_persona_cedulaResponse">
89. <part name="parameters" element="tns:get_persona_cedulaResponse"/>
90. </message>
91. <message name="get_personas">
92. <part name="parameters" element="tns:get_personas"/>
93. </message>
94. <message name="get_personasResponse">
95. <part name="parameters" element="tns:get_personasResponse"/>
96. </message>
97. <message name="get_modalidades">
98. <part name="parameters" element="tns:get_modalidades"/>
99. </message>
100.
<message name="get_modalidadesResponse">
101.
<part name="parameters" element="tns:get_modalidadesResponse"/>
102.
</message>
103.
<portType name="PftWebService">
104.
<operation name="get_persona_cedula">
105.
<input wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_persona_cedula
Request" message="tns:get_persona_cedula"/>
106.
<output wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_persona_cedul
aResponse" message="tns:get_persona_cedulaResponse"/>
107.
</operation>
108.
<operation name="get_personas">
109.
<input wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_personasReques
t" message="tns:get_personas"/>
110.
<output wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_personasRespo
nse" message="tns:get_personasResponse"/>
111.
</operation>
112.
<operation name="get_modalidades">
113.
<input wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_modalidadesReq
uest" message="tns:get_modalidades"/>
114.
<output wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_modalidadesRe
sponse" message="tns:get_modalidadesResponse"/>
115.
</operation>
116.
</portType>
117.
<binding name="PftWebServicePortBinding" type="tns:PftWebService">
118.
<wsp:PolicyReference URI="#PftWebServicePortBindingPolicy"/>
119.
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="documen
t"/>
120.
<operation name="get_persona_cedula">
121.
<soap:operation soapAction=""/>
122.
<input>
123.
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Input_Policy
"/>
124.
<soap:body use="literal"/>
125.
</input>

81

126.
127.
y"/>
128.
129.
130.
131.
132.
133.
134.
"/>
135.
136.
137.
138.
y"/>
139.
140.
141.
142.
143.
144.
145.
"/>
146.
147.
148.
149.
y"/>
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.

<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Polic
<soap:body use="literal"/>
</output>
</operation>
<operation name="get_personas">
<soap:operation soapAction=""/>
<input>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Input_Policy
<soap:body use="literal"/>
</input>
<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Polic
<soap:body use="literal"/>
</output>
</operation>
<operation name="get_modalidades">
<soap:operation soapAction=""/>
<input>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Input_Policy
<soap:body use="literal"/>
</input>
<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Polic
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="PftWebService">
<port name="PftWebServicePort" binding="tns:PftWebServicePortBinding">
<soap:address location="https://localhost:8181/pft-ws/PftWebService"/>
</port>
</service>
</definitions>

Donde se pude visualizar en WSDL que desde la lnea 8 hasta la 79, son aserciones y polticas de
seguridades, descritas a continuacin (Binu, 2015):

sp:AsymmetricBinding.- Lnea 9 a 46, indica que el elemento de esta poltica est


configurado para utilizar criptografa asimtrica de la clave pblica durante el intercambio
de mensajes.

sp:AlgorithmSuite.- Lnea 11 a 15, indica el algoritmo utilizado para la firma, en este caso
se utiliza el algoritmo Basic128.

sp:IncludeTimestamp.- Lnea 18, marca el tiempo que se utiliza con cada mensaje.

sp:InitiatorToken.- Lnea 19 a 28, indica que la clave pblica para firmar el mensaje sera
con certificado X.509 y ser enviado con cada mensaje desde el cliente al servidor y
viceversa.

WssX509V3Token10.- Lnea 24 y 40, indica el tiempo de ejecucin para utilizar el


certificado.

82

sp:OnlySignEntireHeadersAndBody.- Lnea 34, indica que la firma se realizar sobre toda


la cabecera y el cuerpo del mensaje.

sp:SignedEncryptedSupportingTokens.- Lnea 47 a 55, indica que se requiere el cifrado y


encriptado de los tokens.

sp:SamlToken.- Lnea 49 a 53, indica que se utiliza aserciones de seguridad (SAML) como
tokens de seguridad.

sp:WssSamlV20Token11.- Lnea 51, indica que la versin del token SAML es 2.0.

sp:EncryptedParts.- Lnea 64 a 66 (mensaje de entrada) y 73 a 75 (mensaje de salida),


indica las partes del mensaje que sern cifradas, en este caso se indica que se cifrar el
Body del mensaje.

sp:SignedParts.- .- Lnea 68 a 70 (mensaje de entrada) y 76 a 78 (mensaje de salida),


indica las partes del mensaje a firmar, de igual forma se indica que se firmar el Body del
mensaje.

Mediante las polticas de seguridad del WS-Security Policy listadas anteriormente, son las que
definen los requerimientos y lineamientos que debe cumplir el cliente del servicio web para poder
acceder al mismo de forma satisfactoria, por ejemplo estn definidos las aserciones y los tokens
de autenticacin de SAML, los tipos de certificados utilizados, el encriptado y firmado de los
mensajes.
Configuracin de HTTPS.- Para la configuracin del protocolo HTTPS se agreg en el archivo
web.xml del servicio web el siguiente cdigo para que la aplicacin se ejecute sobre el puerto 8181
del servidor de aplicaciones Glassfish. A continuacin se indica el cdigo para tal finalidad:
<security-constraint>
<display-name>SecurityConstraint</display-name>
<web-resource-collection>
<web-resource-name>PftResource</web-resource-name>
<description/>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<description/>
<role-name>wsit</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

83

4.3.2. Aplicacin Cliente Servicio Web


Configuracin SAML.- Una vez implementado el servicio web con la seguridad de autenticacin
SAML, se procedi a la implementacin de una aplicacin cliente del servicio web denominada pftws-client que sirve de cliente y permite acceder a los servicios web, el cual requiere configurar las
respectivas credenciales para la correcta autenticacin con el servicio web. Para realizar la
configuracin se debe proceder como se detalla en el Anexo E.
4.3.3. Filtros de Seguridad
As mismo se desarrollaron algunas clases que permiten mitigar las vulnerabilidades expuestas
en OWASP como es XSS, ClickJacking, y problemas de cabeceras, como podemos ver en la
Figura 35. La mismas que permiten controlar las cabeceras para no permitir la introduccin
maliciosa de los datos de entrada en la aplicacin por parte del usuario, evitar ataques de tipo XSS,
ClickJacking y no permitir que las respuestas del servidor no puedan ser almacenadas en el
navegador.

Figura 35. Clase FiltroSecurity


Fuente: Autor
Elaboracin: Autor

En el archivo de configuracin web.xml se tienen que habilitar los filtros para evitar las
vulnerabilidades de XSS, Clickjacking y problemas de cabeceras, como se muestra en la Figura
36.

84

Figura 36. Configuracin de filtros de seguridad - web.xml


Fuente: Autor
Elaboracin: Autor

Otra configuracin importante que se realiz fue la intercepcin de script a travs de las URL por
parte de los atacantes para luego personalizarlos y enviarlos a peticin al servidor. Para ello se
desarroll

una

clase

denominada

XSSRequestWrapper

HttpServletRequestWrapper, el cdigo es el siguiente (Figura 37):

85

que

extiende

Figura 37. Clase XSSRequestWrapper


Fuente: Autor
Elaboracin: Autor

Para la exposicin de datos sensibles se utiliz un algoritmo de encriptacin DES, la cual permite
encriptar la respuesta del servicio web al cliente. As mismo el cliente podr desencriptar los datos
al momento de recibir la respuesta. Con este mecanismo estamos asegurando la confidencialidad
de la informacin y no pueda ser visualizada por los atacantes. En la Figura 38 se puede visualizar
el cdigo utilizado la encriptacin de los datos en el servicio web.

86

Figura 38. Cdigo para encriptar DES


Fuente: Autor
Elaboracin: Autor

Tambin se configur en el archivo web.xml de la aplicacin cliente del servicio web un comando
que permite evitar la lectura y escritura de scripts por parte de los atacantes, de la siguiente manera:
<session-config>
<cookie-config>
<http-only>true</http-only>
</cookie-config>
</session-config>
Como conclusin parcial de este captulo se puede decir que la implementacin de la solucin
propuesta para el desarrollo de servicios web seguros se lo puede hacer mediante el protocolo de
comunicacin SOAP con su especificacin WS-Security, el cual provee de mecanismos de
autenticacin como el SAML, polticas de seguridad, tokens, criptografa y firmado de mensajes,
todos estos definidos en el documento WSDL con ayuda del framework Metro. Adems de la
seguridad implementada a nivel de codificacin para evitar ataques de SQL Injection y XSS, as
como del control de cabeceras.
Una vez implementada la solucin se procede a realizar sus respectivas validaciones, para
comprobar si la aplicacin cumple con los requerimientos de seguridad (disponibilidad, integridad
y confidencialidad de los datos) planteados anteriormente. En el siguiente captulo de Validacin
se detallan dichas pruebas.

87

CAPTULO V

VALIDACIN

88

En el presente captulo se exponen los resultados de las pruebas realizas en base a tres aspectos:
Diseo Arquitectnico, Codificacin y Seguridad del prototipo; mediante la utilizacin de
herramientas que nos permitirn sacar conclusiones del presente trabajo.
5.1. Validacin de Diseo
Para la validacin del diseo del prototipo se utiliz la herramienta Structural Analysis for Java la
misma que apoya a los desarrolladores a medir la calidad del software a nivel de diseo, donde se
puede visualizar el diseo estructural, la comprensin del cdigo, la medicin de la calidad de
acuerdo a mtricas.
Como resultado se obtuvo el diagrama que se expone en la Figura 39, donde se observa que los
paquetes del prototipo estn definidos, estructurados y distribuidos, separando cada clase de otra,
acorde al diseo propuesto.

Figura 39. Diseo arquitectnico Validacin


Fuente: Autor
Elaboracin: Autor

En la Figura 40, se puede apreciar la implementacin del patrn de diseo Facade, donde se
visualiza la implementacin de la clase AbstractDao.

89

Figura 40. Patrn de Diseo Facade Validacin


Fuente: Autor
Autor: Autor

Una de las propiedades de la herramienta es mostrar un resumen de objetos, relaciones y


dependencias, dichol resultado se visualiza en la Figura 41.

Figura 41. Estabilidad del prototipo - Validacin


Fuente: Autor
Elaboracin: Autor

5.2. Validacin de Cdigo


Para la validacin de codificacin se utiliz la herramienta SonarQube 5.1, la misma que permite
analizar de forma esttica la calidad del cdigo fuente. SonarQube es una herramienta libre que
permite identificar mtricas que ayudan a mejorar la codificacin; entre las mtricas se encuentran:
cdigo duplicado, estndares de codificacin, errores, comentarios, Technical Debt, etc. Adems
permite la instlalacin de plugins que ayudan a validar el diseo arquitectnico. En la Figura 42 se
muestra la primera iteracin de validacin del prototipo y en la Tabla 10 se exponen los resultados
de ciertas mtricas.

90

5.2.1. Primera Iteracin

Figura 42. Primera Iteracin SonarQube


Fuente: Autor
Elaboracin: Autor

Donde como resultados se obtuvo lo siguiente:

Lneas de Cdigo: 3065

Archivos: 42

Funciones: 178

SQALE Rating: A

Technical Debt Ratio: 2.4 %

Issues: 86

91

Tabla 10. Prueba de cdigo con SonarQube - Iteracin 1


ISSUES
SOLUCION
Los campos de una clase "Serializable"
deben ser o bien transitoria o serializable

NIVEL

CANTIDAD

Critical

57

Major

25

Minor

Serializar todas las clases.

Al manejar una excepcin capturada,


dos informaciones obligatorias deben
ser registrados:
Manejadores

de

excepciones

deben

preservar la excepcin original

Algunos contextos para facilitar la


reproduccin de la cuestin.
Excepcin de la original, por su
mensaje y seguimiento de la pila.

Mtodos no deben estar vacos

Matrices vacas y colecciones deben ser


devueltos en lugar de null
Las secciones de cdigo no deben
"comentadas"
Parmetros del mtodo, excepciones
capturadas y variables foreach no deben
ser reasignados
Las clases de "sun. *" Paquetes no deben
utilizarse
Ouputs estndar no deben utilizarse
directamente para registrar nada

Bloques duplicados

Los miembros de una declaracin de


interfaz o clase deben aparecer en un
orden predefinido

Importaciones intiles deben retirarse

Comentar por qu el mtodo est


vaco.

Retornar en valor diferente de null

Eliminar las lneas de cdigo


comentadas

Crear una variable global para


reutilizarla.

Paquetes sun.* no son considerados


parte del Api de Java.
Utilizar loggers para presentar
excepciones.
Crear mtodos para poder reutilizar
cdigo.

Poner en Orden las variables que se


utilizan

Eliminar importaciones que no se


utilizan

92

Los literales de cadena no deben ser

Crear una variable string para poder

duplicados

reutilizar luego.

El paquete sin nombre por defecto no debe


utilizarse

Eliminar los paquetes por defecto que


se estn utilizando en la misma clase
por buena prctica de codificacin.

Fuente: Autor
Elaboracin: Autor

5.2.2. Segunda Iteracin


Una vez seguidas las debidas correcciones arrojadas por la herramienta en la primera iteracin,
procedimos a realizar la segunda iteracin, como se muestra en la Figura 43 los siguientes
resultados:

Figura 43. Segunda Iteracin SonarQube


Fuente: Autor
Elaboracin: Autor

Lneas de Cdigo: 3062

Archivos: 41

Funciones: 179

SQALE Rating: A

Technical Debt Ratio: 1.9 %

Issues: 57
93

Los 2 tipos de issues encontrados con la herramienta son sobre:

Los campos de una clase "Serializable" deben ser o bien transitoria o serializable.

Las clases de "sun. *" Paquetes no deben utilizarse

Estos dos issues encontrados por la herramienta no se pudieron resolver ya que todas las clases
se encuentran correctamente serializadas e igualmente sale como error en la herramienta. El otro
issue se refiere a un paquete utilizado ya no pertenece al API de Java.
5.3. Validacin de Seguridad
5.3.1. Validacin con Herramientas
Como ya se mencion anteriormente SOAP permite la construccin de servicios web seguros con
la implementacin de estndares del WS-Security, sin embargo es necesario realizar siempre
pruebas de seguridad para encontrar algn fallo que pueda existir en el prototipo. Para ello se han
seleccionado las siguientes herramientas:

OWASP ZAP 2.4.- Es una herramienta gratuita y multiplataforma para el escaneo de


vulnerabilidades en aplicaciones web mediante pruebas de penetracin, con esta
herramienta se puede monitorear todas las peticiones y respuestas entre el cliente y
servidor y localizar recursos en el servidor de aplicaciones, etc.

Vega Subgraph 1.0.- Vega es un escner de seguridades en aplicaciones web, puede


encontrar vulnerabilidades como XSS, SQL Injection, problemas de directorios, etc. Es una
herramienta libre y multiplataforma al igual que OWASP ZAP.

Wireshark 1.12.- Es un analizador de trfico de red, permite capturar y monitorizar los


paquetes que pasan en vivo por la interfaz de red de un equipo. Se puede analizar la
informacin mediante filtros que se desee capturar, adems posee una interfaz amigable y
el libre.

En primer lugar se realizar pruebas al prototipo sin seguridad que ser la primera iteracin de la
validacin con las herramientas OZASP ZAP y Vega, los resultados se detallan en la Tabla 11:

94

Tabla 11. Alertas del prototipo sin seguridad


HERRAMIENTA

NO. DE

NIVEL DEL

ALERTAS

RIESGO

Directory Traversal

Alto

X-Frame-Options Header Not Set

Medio

Medio

Web Browser XSS Protection Not Enabled

Bajo

X-Content-Type-Options Header Missing

Bajo

X-Frame-Options Header Not Set

Informativo

TIPO DE ALERTA

Incomplete or No Cache-control and


OWASP ZAP

Vega

Pragma HTTP Header Set

Fuente: Autor
Elaboracin: Autor

Para la vulnerabilidad de Exposicin de datos sensibles, con la herramienta Wireshark se procedi


a realizar una prueba para verificar el trfico que existe al hacer una peticin HTTP hacia el servicio
como se puede ver en la Figura 44:

95

Figura 44. Captura del trfico con HTTP - Wireshark


Fuente: Autor
Elaboracin: Autor

Donde se puede visualizar los datos que viajan en respuesta a la peticin, ya que se encuentra en
un protocolo no seguro como es el HTTP.
La segunda iteracin fue realizada tomando en cuenta la implementacin de estndares y
recomendaciones de seguridad, como se puede ver en la Tabla 14:
Tabla 12. Alertas del prototipo con seguridad
HERRAMIENTA

OWASP ZAP

NO. DE

NIVEL DEL

ALERTAS

RIESGO

Directory Traversal

Alto

X-Frame-Options Header Not Set

Medio

Medio

Web Browser XSS Protection Not Enabled

Bajo

X-Content-Type-Options Header Missing

Bajo

TIPO DE ALERTA

Incomplete or No Cache-control and Pragma


HTTP Header Set

96

Page Fingerprint Differential Detected -

Alto

Character Set Not Specified

Informativo

X-Frame-Options Header Not Set

Informativo

Possible Local File Include


Vega

Fuente: Autor
Elaboracin: Autor

Donde las alertas encontradas son:

Directory Transversal.- Este tipo de inseguridad ocurre cuando no existe una validacin de
usuarios, permitiendo el acceso a directorios restringidos. Mediante esta vulnerabilidad los
atacantes pueden visualizar informacin secreta, descargando estos archivos privados.

X-Frame-Options Header Not Set.- La cabecera X-Frame-Option indica si un navegador


debe permitir hacer una pgina en un <frame>, <iframe> o un <object>. Proporciona
proteccin contra ataque Clickjacking, que es una tcnica para engaar al usuario para que
haga click en un enlace haciendo que el contenido de la pgina se incruste en otros sitios.

Web Browser XSS Protection Not Enabled.- La cabecera XSS Protection permite activar y
desactivar filtros XSS.

X-Content-Type-Options Header Missing.- Esta cabecera impide que los navegadores lean
otro tipo de contenido al declarado.

Page Fingerprint Differential Detected.- Possible Local File Include.- Significa que el
atacante puede tener acceso no autorizado a archivos confidenciales de la aplicacin web,
en alguna ruta o entrada dada en la URL.

Character Set Not Specified.- Cuando no se especifica un conjunto de caracteres en la


cabecera de la respuesta de tipo de contenido o en el cuerpo de la cabecera de la respuesta
del navegador.

En la Figura 35 mencionada en el captulo de implementacin, se puede observar el cdigo de


configuracin de las cabeceras para evitar las vulnerabilidades mencionadas anteriormente:
De igual manera, con la herramienta Wireshark se realiz la deteccin del trfico en una peticin
al servicio web, pero en este caso se implement el protocolo seguro HTTPS, mediante la
utilizacin de un canal seguro como SSL, para garantizar el envo de los datos de una forma
segura; donde se puede observar en la Figura 45 que los datos no se los puede visualizar como
en el trafico anterior con el protocolo HTTP.

97

Figura 45. Captura del trfico con HTTPS - Wireshark


Fuente: Autor
Elaboracin: Autor

Adems se implement SAML para la parte de autenticacin de los servicios web; si no se hace
las respectivas configuraciones tanto en el cliente como en el servicio, el cliente no podr acceder
a los datos que retorne el servicio web, como se puede ver la Figura 46:

Figura 46. Cliente sin autenticacin SAML


Fuente: Autor
Elaboracin: Autor

La aplicacin cliente no puede acceder a la informacin debido a los siguientes errores descritos a
continuacin (Figura 47):

Grave:

WSS1500: el manejador de nombres de usuario no se ha configurado

correctamente mediante la devolucin de llamada y es nulo. (No est configurado).

Grave:

WSS0216: Se ha producido un error al utilizar CallbackHandler para:

UsernameCallback

Grave: WSS0217: se ha producido un error al utilizar el mtodo CallbackHandler handle().

98

Figura 47. Captura de errores de autenticacin SAML


Fuente: Autor
Elaboracin: Autor

Son errores de configuracin de Autenticacin y Autorizacin de Security Assertion Markup


Language (SAML), estos errores se resuelven con las respectivas configuraciones en el cliente y
en el servicio, mediante el mecanismo se seguridad SAML Sender Vouches with Certificates.
5.3.2. Validacin Manual
Para las pruebas de validacin de SQL Injection y XSS, se procedi a realizar ataques de forma
manual. Primeramente en un prototipo de la aplicacin web sin seguridades, sin validacin de datos
de entrada y sin el uso de procedimientos almacenados. En la Figura 48, se puede observar cmo
se realiza una consulta en el servicio web para obtener una persona con el nmero de identificacin
que se enva como parmetro.

Figura 48. Consulta de personas por cdula


Fuente: Autor
Elaboracin: Autor

99

Una de las vulnerabilidades que pueden ocurrir sobre un servicio web es la inyeccin SQL, en la
Figura 49, se observa que se puede introducir en la URL una consulta para obtener los datos de
una persona por un criterio de bsqueda, le introducimos la siguiente inyeccin SQL:
http://localhost:8080/pft-ws-client-vulnerable/PersonaServlet?cedula= ''or ''=''

Figura 49. Ataque SQL Injection


Fuente: Autor
Elaboracin: Autor

Se puede observar que al no contener ninguna seguridad para evitar esta vulnerabilidad es posible
acceder a todos los datos tan solo enviando como para parmetro el siguiente cdigo SQL: ''or
''=''. Muchos de los casos de las Inyecciones SQL se dan por el cdigo que se utiliza ya sea en
una consulta en lenguaje SQL, o en nuestro caso que se utiliza JPA.
Por lo tanto el hecho que se utilice un ORM, no significa que no exista riego en los ataques SQL.
En la Figura 50, se muestra el cdigo incorrecto que se utiliza para obtener las personas por cdula.

Figura 50. Cdigo incorrecto de consulta SQL


Fuente: Autor
Elaboracin: Autor

100

Se puede observar que se utiliza una consulta nativa utilizando JPA, sin embargo la consulta queda
abierta para que se pueda introducir mediante el parmetro cedula una consulta SQL
En la Figura 51, se indica el cdigo correcto a implementar para evitar un ataque SQL Injection.

Figura 51. Cdigo correcto de consulta SQL


Fuente: Autor
Elaboracin: Autor

Se puede observar que la entrada que enva un usuario como parmetro es preparada en
query.setParameter (cedula) esto hace que todas las entradas sean tomadas como texto y no
como sentencias SQL, es decir si se enva ''or ''='', significa que es una cedula y no sentencia
SQL. En la Figura 52, se observa que no se produce el mismo resultado del caso anterior, es decir
no se puede hacer un ataque de SQL Injection.

Figura 52. Aplicacin Web contra ataque SLQ Injection


Fuente: Autor
Elaboracin: Autor

Para mayor seguridad, como se mencion anteriormente se recomienda el uso de procedimientos


almacenados, que limitan las sentencias SQL maliciosas insertadas por el usuario, previniendo as
los ataques de SQL Injection.
Otro ataque que se puede realizar es XSS, introduciendo cdigo JavaScript en el prototipo para
alterar el comportamiento del mismo. Por ejemplo, en una aplicacin vulnerable se puede insertar
un cdigo malicioso por medio de parmetros enviados a la base de datos, en la Figura 53 se
observa el servicio web que se puede insertar un script en un servicio web para actualizar la clave,

101

cuyo script enviado se almacenar en la columna PER_CLAVE de la base de datos, quedando la


URL de la siguiente manera:
http://localhost:8080/pft-ws-clientvulnerable/PersonaServlet?user=admin&&claveAnterior=admin123&&claveNueva=%3Cscript%3Eal
ert(%27hola%27)%3C/script%3E

Figura 53. Insertar cdigo JavaScript en la base de datos


Fuente: Autor
Elaboracin: Autor

En la Figura 54, se puede comprobar que se insert el cdigo script en la base de datos sin ningn
problema, ya que no existe ninguna validacin de los datos de entrada en el prototipo, ahora al
momento que se desee recuperar dicha clave se ver reflejada dicha alerta, a este tipo de ataque
se lo conoce como XSS almacenado.

Figura 54. Resultado de la Insercin de script en la base de datos


Fuente: Autor
Elaboracin: Autor

En la Figura 55, podemos observar en el navegador web el servicio para recuperar la clave de un
usuario anterior, donde se ejecuta el script almacenado en la base de datos.

102

Figura 55. Ataque XSS


Fuente: Autor
Elaboracin: Autor

Para evitar este tipo de ataque se procedi a la validacin los datos de entradas en el prototipo
donde se utiliz un cdigo que limpia los parmetros enviados, la podemos observar en la Figura
48, anteriormente citada, que no permite la introduccin de cdigos maliciosos.

103

CONCLUSIONES
Al trmino del presente proyecto fin de carrera y cumpliendo con cada objetivo se ha llegado a las
siguientes conclusiones:

La especificacin WS-Security permite utilizar mecanismos de seguridad de autenticacin


SAML con certificados digitales, as como mecanismos de cifrado y firmado provistos por
la herramienta WSIT con el fin de proteger el transporte de los mensajes.

Es necesario utilizar el mecanismo de seguridad SAML Sender Vouches with Certificates,


del lado del servidor y del cliente para que las peticiones del cliente sean validadas y
consumidas mediante credenciales en formatos de tokens X.509 SAML por el servicio web.

La implementacin de HTTPS en el servicio web ayuda a prevenir ataques de tipo sniffer,


ya que crea un canal seguro mediante SSL para la comunicacin entre el cliente y servidor,
garantizando la integridad y confidencialidad de los datos.

JPA y la implementacin de procedimientos almacenados del lado de la codificacin en la


aplicacin y de la programacin a nivel de base de datos apoyan en la reduccin de
ataques de tipo SQL Injection.

La implementacin de funciones y de cabeceras seguras como: Control Cach, X-Frame


Options, XSS Protection, configuradas en el servicio y en el web.xml permiten evitar
ataques ClickJacking y XSS.

El framework Metro permite la implementacin de JAX-WS y WSIT para la comunicacin


a travs de XML con el protocolo SOAP y la especificacin WS-Security de forma
automatizada, ocultando la complejidad de los mensajes SOAP.

Con la implementacin de WSIT se logr seguridad de la mensajera de los servicios web


mediante especificaciones del WS-Security, mecanismos de autenticacin de cifrado y de
firmado de los mensajes, permitiendo integridad y confidencialidad de los datos.

SonarQube a travs del anlisis esttico permite validar la calidad del cdigo, Structural
Analysis for Java permite la validacin de la estructuracin de las clases del prototipo
representando las misma de forma visual.

Herramientas como OWASP ZAP, VEGA y Wireshark permiten a travs de un anlisis


dinmico obtener un diagnstico sobre que vulnerabilidades hay que mitigar en la
implementacin del prototipo.

104

RECOMENDACIONES

Para el anlisis de cdigo de proyectos desarrollados en la plataforma Java es


recomendable la utilizacin de herramientas que permitan validar cdigo como SonarQube
que es una herramienta libre y posibilita la integracin con plugins que permiten un anlisis
profundo en el cdigo; para el anlisis del diseo arquitectnico se recomienda utilizar una
herramienta libre como Structural Analysis for Java que ayuda a visualizar la estructura del
software, sus componentes y como se interrelacionan entre s.

Para el desarrollo de servicios web con el protocolo SOAP se recomienda utilizar el API de
Java JAX-WS, que permite el uso de tecnologas como como Metro y WSIT que ayudan a
la implementacin de estndares de seguridad como WS-Security para proteger la
informacin sensible.

Es recomendable la aplicacin e implementacin del estndar de SOAP y de WS-Security,


cuando se trate de seguridad en servicios web, ya que esta cuenta con muchas otras
especificaciones

como

WS-Trust,

WS-Reability,

WS-SecureConversation,

WS-

AtomicTransaction, WS-Coordination, XKMS, XAMCL, etc., que no se tomaron en cuenta


en este estudio.

Se recomienda la utilizacin de Metro en la codificacin ya que es un framework para el


desarrollo de servicios web de alto rendimiento, extensible y fcil de usar en varios
servidores web como JBoss, Glassfish, Oracle Web Logic. Adems este framework soporta
las tecnologas JAX-WS para la implementacin de los servicios web y WSIT para la parte
de seguridad e interoperabilidad.

Es recomendable realizar un estudio de factibilidad y evaluar la pertinencia de la adopcin


de una arquitectura orientada a servicios en cualquier empresa, debido a que este cambio
contempla ampliacin de costos y tiempo, y no implementar estas nuevas tecnologas solo
por el hecho que estn en moda, sino de acuerdo a las necesidades del negocio.

Hay que tener en cuenta que no se pueden resolver algunos de los problemas encontrados
por SonarQube, ya que esta herramienta posee estndares no acordes con el lenguaje de
programacin Java, como por ejemplo serializacin de clases y la utilizacin de APIs
antiguas.

105

BIBLIOGRAFA
Ahumada Ahumada, J. F. (2013). Documentacin de Arquitecturas de Sistemas en un Banco.
Retrieved
from
http://www.tesis.uchile.cl/bitstream/handle/2250/113666/cfahumada_fa.pdf?sequence=1
Almeida, A. S., & Perez, V. (2011). Arquitectura de Software: Estilos y Patrones. Universidad
Nacional
de
la
Patagonia
San
Juan
Bosco.
Retrieved
from
http://www.dit.ing.unp.edu.ar/graduate/bitstream/123456789/203/1/Tesina Arquitectura
de Soft.pdf
Anaya Lopez, E. (2011). Implementacin de controles de seguridad en Arquitecturas
Orientadas a Servicios (SOA) para servicios web. Instituto Politcnico Nacional.
Retrieved from http://148.204.210.201/tesis/1313442753812TesisEmilioAn.pdf
Andrade, K., Jimenez, J., & Valencia, O. (2013). Anlisis para la deteccin de vulnerabilidades
en la aplicacin web COLIBRI II. Retrieved from file:///C:/Users/Miguel
Tenezaca/Downloads/1-1-1-PB.pdf
Aperador, M. (2012). Caractersticas de los Servicios web y como consumirlos. Retrieved from
https://prezi.com/lwbginvwiod4/caracteristicas-de-los-servicios-web-y-comoconsumirlos/
Arias, J., & Fernndez, N. (2009). Servicios Web. Madrid-Espaa. Retrieved from
http://ocw.uc3m.es/ingenieria-telematica/tecnologias-de-distribucion-decontenidos/transparencias_tdc/servicios-web-i-soap-wsdl.pdf
Arquitectura Orientada a Servicios. (2011). Retrieved December 5, 2014, from http://soafpuna.blogspot.com/2011/11/ventajas-y-desventajas.html
Arsanjani, A. (2004). Service-oriented modeling and architecture, 114. Retrieved from
http://www.ibm.com/developerworks/webservices/library/ws-soa-design1/ws-soadesign1-pdf.pdf
Barraza, F. (n.d.). Modelado y Diseo de Arquitectura de Software. Cali. Retrieved from
http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:s2_conceptosdemodelado.p
df
Binu, G. (2015). Globinch Foro de Java. Retrieved from http://java.globinch.com/enterprisejava/web-services/jax-ws/secure-web-services-signatures-encryption-security-withmetro/
Bosch, J. (2000). Design and Use of Software Architectures. Harlow-UK: Addison-Wesley.
Retrieved
from
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.105.6346&rep=rep1&type=pdf
Buschmann, F., Meunie, R., Rohnert, H., Sommerlad, P., & Stal, M. (2000). Pattern Oriented
Software Architecture. A System of Patterns. Inglaterra: John Wiley & Sons.
http://doi.org/ISBN: 978-0-471-95869-7

106

Camacho, E., Cardeso, F., & Nuez, G. (2004). Arquitecturas de Software. Gua de
estudio.[En Lnea], 158. Retrieved from http://prof.usb.ve/lmendoza/Documentos/PS6116/Guia Arquitectura v.2.pdf
Cervantes,
H.
(2010).
Arquitectura
de
Software.
http://sg.com.mx/revista/27/arquitectura-software#.VKgIStKG9Y5

Retrieved

from

Chase, N. (2011). IBM- DeveloperWorks. Retrieved August 5, 2014, from


http://www.ibm.com/developerworks/ssa/webservices/tutorials/ws-understand-webservices1/
Clements, P., & Northrop, L. (1996). Software architecture: An executive overview.
Crespo Crespo, Augusta, M., & Ramos Choes, R. (2012). Estudio del Impacto Financiero de
las Vulnerabilidades de las Pginas Web de los Bancos en Ecuador. Universidad
Politcnica
Salesiana
sede
Guayaquil.
Retrieved
from
http://dspace.ups.edu.ec/bitstream/123456789/3223/1/UPS-GT000334.pdf
Defaz Toapanta, X. E. (2006). Capitulo 2 Anlisis pertinente de riesgos y vulnerabilidades.
Universidad
Tcnica
del
Cotopaxi.
Retrieved
from
http://181.112.224.103/bitstream/27000/536/2/T-UTC-1052%282%29.pdf
Enriquez Huaca, E., & Caraguay, J. (2011). Sistema de Gestin de Historias Clnicas para el
Departamento de Bienestar Universitario de la UTN. Univerisidad Tcnica del Norte.
Retrieved from http://repositorio.utn.edu.ec/bitstream/123456789/587/1/CAPITULOS.pdf
Fernndez, L. F. (2006). Arquitectura de Software. Metodologas Agiles, 42. Retrieved from
http://www.ozarate.net/articulos/arquitectura_sw_sg_2006.pdf
Fernndez, N. (2012). Tecnologas de Distribucin de Contenidos. Espaa. Retrieved from
http://ocw.uc3m.es/ingenieria-telematica/tecnologias-de-distribucion-decontenidos/transparencias_tdc/introduccion.pdf/
Gardazi, S. U., & Shahid, A. A. (2009). Survey of software architecture description and usage
in software industry of Pakistan. Emerging Technologies, 2009. ICET , 395402.
Retrieved from http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5353137
Gomez,
D.
(2013).
Oracle
From
Guatemala.
Retrieved
http://oraclefromguatemala.blogspot.com/2013/02/caracteristicas-de-un-serviciosoa.html

from

Gonzles Quiroga, M. (2011). Estudio de Arquitecturas de Redes Orientadas a Servicios.


Retrieved
from
http://upcommons.upc.edu/pfc/bitstream/2099.1/12312/1/ESTUDIO_DE_ARQUITECTU
RAS_DE_REDES_ORIENTADAS_A_SERVICIO.pdf
Guamn Quinche, R. (n.d.). Seguridad en Entornos Web para Sistemas de Gestin
Acadmica.
Retrieved
from
http://repositorio.educacionsuperior.gob.ec/bitstream/28000/120/1/Seguridad
de
entornos web.pdf

107

Hermoso Metaute, A. (2013). Seguridad en Aplicativos Web. Universitat de Barcelona.


Retrieved
from
http://diposit.ub.edu/dspace/bitstream/2445/49106/1/AdrianHermoso_memoria.pdf
Iturricha. Ibai, & Urkizu, B. (2010). Seguridad en entornos SOA. Retrieved from
https://www.google.com.ec/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uac
t=8&ved=0CCQQFjAB&url=http%3A%2F%2Fwww.euskadinnova.net%2Fdocumentos%
2F1241.aspx&ei=zhuIVZn1IYGegwT58o2QCQ&usg=AFQjCNHepejSEqcPcKDNkjAPUb
PTrd8k6g
Jitta, N. (2012). XTIVIA. Retrieved from https://www.xtivia.com/configuring-liferay-6-1-eesaml-identity-provider-service-provider/
Lewis, G. a. (2008). Service-Oriented Architecture and its Implications for Software Life Cycle
Activities. Agenda.
McDonald, C. (2009). Interoperable Web Services with JAX-WS and WSIT. Retrieved from
http://www.slideshare.net/caroljmcdonald/wsitrestcmcdonald
Microsoft Developer Network Chapter 1: Service Oriented Architecture (SOA). (2014).
Retrieved
November
19,
2014,
from
http://msdn.microsoft.com/enus/library/bb833022.aspx
National Security Agency. (n.d.). Service Oriented Architecture Security Vulnerabilities Web
Services.
Retrieved
from
https://www.nsa.gov/ia/_files/factsheets/soa_security_vulnerabilities_web.pdf
Navarro Marset, R. (2006). Rest vs Web Services, 19. Retrieved
http://users.dsic.upv.es/~rnavarro/NewWeb/docs/RestVsWebServices.pdf

from

Oracle. (n.d.). Oracle- Patrones J2EE Core - Data Access Object. Retrieved from
http://www.oracle.com/technetwork/java/dataaccessobject-138824.html
Ordez Len, P. R. (2010). Definicin de un esquema de seguridad en servicios web para la
Universidad Tcnica Particular de Loja. Universidad Tcnica Particula de Loja. Retrieved
from http://dspace.utpl.edu.ec//handle/123456789/1585
OWASP. (2013). OWASP The Open Web Application Security Project. Retrieved from
https://www.google.com.ec/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CD8Q
FjAE&url=http%3A%2F%2Fowasptop10.googlecode.com%2Ffiles%2FOWASP%2520T
op%252010%2520-%25202013.pdf
Patio Castillo, L. G. (2014). Anlisis comparativo de Metro y AXIS2 para el desarrollo de
aplicaciones que consuman servicios web WCF en la ESPOCH. Escuela Superior
Pplitcnica
de
Chimborazo.
Retrieved
from
http://dspace.espoch.edu.ec/bitstream/handle/123456789/3325/18T00548.pdf
Reynoso, C. (2004). Introduccin a la Arquitectura de Software. Universidad de Buenos Aires,
127. Retrieved from http://carlosreynoso.com.ar/archivos/arquitectura/Arquitecturasoftware.pdf

108

Reynoso, C. B. (2004). Introduccin a la Arquitectura de Software. Retrieved from


http://univirtual.unicauca.edu.co/moodle/pluginfile.php/24153/mod_resource/content/0/L
ectura/Estilos_y_patrones.doc
Reynoso, C., & Kicillof, N. (2004). Estilos y Patrones en la Estrategia de Arquitectura de
Microsoft
Estilos
arquitectnicos.
Retrieved
from
http://carlosreynoso.com.ar/archivos/arquitectura/Estilos.PDF
Rivera Posso, A. N. (2004). Estudio de la Arquitectura de Software: Diseo e implemnetacion
de un sistema de planificacion de recursos empresariales. Obsecolosceibos.com.
Retrieved
from
http://www.obsecolosceibos.com/wpcontent/uploads/2013/12/Proyecto_ObsecoLosCeibos.pdf
Salgado, L., Ron, M., & Solis, F. (2014). Anlisis de riesgos de las aplicaciones web de la
Superintendencia de Bancos y Seguros, utilizando las recomendaciones Top Ten de
OWASP. Retrieved from http://repositorio.espe.edu.ec/bitstream/21000/8246/1/AC-SIESPE-047920.pdf
Senmart, E. (2010). Blogging laSalle - Networking and Internet Tecnologies. Retrieved
December
17,
2015,
from
http://blogs.salleurl.edu/networking-and-internettechnologies/ws-security-wss/
Serrano, J. M. (2007). Arquitectura de Software Parte 1: Introduccin (Vol. 35). Retrieved from
http://zenon.etsii.urjc.es/docencia/as/material/tema2.pdf
Sommerville, I. (2011). Ingeniera de Software. (L. Castillo & V. Campos, Eds.) (9na ed.).
Mexico: Pearson Educacion.
Sosnoski, D. (2011). Java web services: Modeling and verifying WS-SecurityPolicy. Retrieved
from http://www.ibm.com/developerworks/library/j-jws21/
Tedeschi, N. (2014). Microsoft Developer Network Qu es un Patrn de Diseo? Retrieved
November 8, 2014, from http://msdn.microsoft.com/es-es/library/bb972240.aspx
Venete, A. (2011). Introduccion a los Patrones de Arquitectura. Retrieved from
http://mahara.uji.es/artefact/file/download.php?file=54534&view=4648

109

ANEXOS

110

A.

Modelo Entidad-Relacin de base de datos.

Figura 56. Modelo Entidad Relacin de la base de datos


Fuente: Autor
Elaboracin: Autor

B.

Procedimientos almacenados implementados.

A continuacin en la Tabla 13 se detallan los procedimientos almacenados creados y utilizados en


la implementacin del prototipo.
Tabla 13. Procedimientos almacenados utilizados

NOMBRE

PARMETROS

get_modalidades

No aplica

get_all_persona

No aplica

get_persona_byIdentific
acion
Fuente: Autor
Elaboracin: Autor

DNI VARCHAR(250)

RESULTADO
Permite obtener todos los programas
acadmicos
Permite devolver todos los usuarios
Permite devolver un usuario que coincida
con el DNI ingresado como parmetro.

C.

Documento WSDL del servicio web PftWebService implementado sin seguridad.


1.
2.

3.
4.
5.

6.
7.

8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.

<!-Published by JAX-WS RI (http://jax-ws.java.net). RI's version is Metro/2.3.1-b419


(branches/2.3.1.x-7937; 2014-08-04T08:11:03+0000) JAXWS-RI/2.2.10-b140803.1500 JAXWSAPI/2.2.11
JAXB-RI/2.2.10-b140802.1033
JAXB-API/2.2.12-b140109.1041
svnrevision#unknown.
-->
<!-Generated by JAX-WS RI (http://jax-ws.java.net). RI's version is Metro/2.3.1-b419
(branches/2.3.1.x-7937; 2014-08-04T08:11:03+0000) JAXWS-RI/2.2.10-b140803.1500 JAXWSAPI/2.2.11
JAXB-RI/2.2.10-b140802.1033
JAXB-API/2.2.12-b140109.1041
svnrevision#unknown.
-->
<definitions
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd"
xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://ws.wspft.utpl.edu/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="http://ws.wspft.utpl.edu/"
name="PftWebService">
</types>
<message name="get_persona_cedula">
<part name="parameters" element="tns:get_persona_cedula"/>
</message>
<message name="get_persona_cedulaResponse">
<part name="parameters" element="tns:get_persona_cedulaResponse"/>
</message>
<message name="get_personas">
<part name="parameters" element="tns:get_personas"/>
</message>
<message name="get_personasResponse">
<part name="parameters" element="tns:get_personasResponse"/>
</message>
<message name="get_modalidades">
<part name="parameters" element="tns:get_modalidades"/>
</message>
<message name="get_modalidadesResponse">
<part name="parameters" element="tns:get_modalidadesResponse"/>
</message>
<portType name="PftWebService">
<operation name="get_persona_cedula">
<input wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_persona_cedulaRequest"
message="tns:get_persona_cedula"/>
<output wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_persona_cedulaResponse
" message="tns:get_persona_cedulaResponse"/>
</operation>
<operation name="get_personas">
<input wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_personasRequest" messag
e="tns:get_personas"/>
<output wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_personasResponse" mess
age="tns:get_personasResponse"/>
</operation>
<operation name="get_modalidades">
<input wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_modalidadesRequest" mes
sage="tns:get_modalidades"/>
<output wsam:Action="http://ws.wspft.utpl.edu/PftWebService/get_modalidadesResponse" m
essage="tns:get_modalidadesResponse"/>
</operation>
</portType>
<binding name="PftWebServicePortBinding" type="tns:PftWebService">
<wsp:PolicyReference URI="#PftWebServicePortBindingPolicy"/>
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<operation name="get_persona_cedula">
<soap:operation soapAction=""/>
<input>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Input_Policy"/>
<soap:body use="literal"/>
</input>

113

50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.

<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Policy"/>
<soap:body use="literal"/>
</output>
</operation>
<operation name="get_personas">
<soap:operation soapAction=""/>
<input>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Input_Policy"/>
<soap:body use="literal"/>
</input>
<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Policy"/>
<soap:body use="literal"/>
</output>
</operation>
<operation name="get_modalidades">
<soap:operation soapAction=""/>
<input>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Input_Policy"/>
<soap:body use="literal"/>
</input>
<output>
<wsp:PolicyReference URI="#PftWebServicePortBinding_get_personas_Output_Policy"/>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="PftWebService">
<port name="PftWebServicePort" binding="tns:PftWebServicePortBinding">
<soap:address location="http://localhost:8080/pft-ws/PftWebService"/>
</port>
</service>
</definitions>

114

D.

Configuracin SAML con WSIT Servicio web.

A continuacin se detallan los pasos a seguir para la configuracin del mecanismo de seguridad
SAML en el servicio web:
1. Seleccionar el servicio web y editar los atributos del servicio web, como se visualiza en la
Figura 57:

Figura 57. Editar Atributos del Servicio Web Configuracin


Fuente: Autor
Elaboracin: Autor

2. Seleccionar el mecanismo de seguridad que vamos a implementar en el prototipo de la


aplicacin web. En este caso ser SAML Authorization Vouches with Certificates,
mecanismo provedo por WSI, como se muestra en la Figura 58:

115

Figura 58. Seleccin del mecanismos de seguridad - Configuracin WSIT


Fuente: Autor
Elaboracin: Autor

3. Este mecanismo se seguridad trabaja con certificados SSL, por lo cual se debe hacer
referencia a la ubicacin de estos archivos que contiene informacin para que el cliente del
servicio web pueda autenticarse satisfactoriamente, as mismo de establecer las
contraseas del keystore y truststore. Cabe recalcar que para el presente proyecto se usar
los certificados que viene predefinidos en el servidor de aplicaciones Glassfish. En las
Figuras 59 y 60 se muestra dicha configuracin.

116

Figura 59. Configuracin Keystore


Fuente: Autor
Elaboracin: Autor

Figura 60. Configuracin Truststore


Fuente: Autor
Elaboracin: Autor

4. Para la configuracin del Firmado y Encriptado de los mensajes SOAP, se lo hace de la


siguiente manera (Figura 61):

117

Figura 61. Encriptacin y Firmado de mensajes SOAP


Fuente: Autor
Elaboracin: Autor

118

E.

Configuracin SAML con WSIT Cliente del Servicio web.

A continuacin se indican los pasos para configurar las credenciales de seguridad en el lado del
cliente para que pueda acceder correctamente al servicio web con el mecanismo de autenticacin
SAML.
1. Para este paso el servicio web tiene que estar ejecutndose con todas las polticas de
seguridad para que la importacin del archivo WSDL sea correcto en el cliente (Figura 62).

Figura 62. Importacin del WSDL en el cliente


Fuente: Autor
Elaboracin: Autor

2. Una vez cargado el Servicio web en el cliente, editamos los atributos del servicio web
(Figura 63).

Figura 63. Editar atributos del servicio web cliente


Fuente: Autor
Elaboracin: Autor

119

3. Proporcionar los certificados Keystore y Truststore configurados en el servicio web


anteriormente (Figura 64 y 465).

Figura 64. Configuracin Keystore Cliente


Fuente: Autor
Elaboracin: Autor

Figura 65. Configuracin Truststore Cliente


Fuente: Autor
Elaboracin: Autor

4. Por ltimo se debe seleccionar una clase llamada SamlCallBackHandler que realizar la
autorizacin a los servicio mediante los certificador SSL, como se muestra en la Figura 45.
La clase SamlCallBackHandler se descarga de la pgina:
https://xwss.java.net/servlets/ProjectDocumentList?folderID=6645&expandFolder=6645&f
olderID=6645, y se lo implementa en nuestro proyecto cliente y se modifica con los datos
de los certificados utilizados.

Figura 66. Configuracin SamlCallbackHandler Cliente


Fuente: Autor
Elaboracin: Autor

120

You might also like