Download modelo de gestión de servicios pki basado en una arquitectura

MODELO DE GESTIÓN DE SERVICIOS PKI BASADO EN UNA ARQUITECTURA
ORIENTADA A SERVICIOS
Autores:
EDGAR HERNÁN LÓPEZ CÁRDENAS
DIANA CAROLINA VALBUENA PABÓN
Proyecto de grado presentado para optar al título de Ingeniero de Sistemas
Director de Trabajo de Grado:
Juan Carlos Huertas Amaya
Ingeniero de Sistemas,
Director de la Unidad de Seguridad Informática
Banco de la República
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMAS
SANTA FÉ DE BOGOTÁ, D.C.
NOVIEMBRE DE 2006
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMAS
Rector Magnífico:
Padre Gerardo Remolina Vargas S.J.
Decano Académico Facultad de Ingeniería:
Ingeniero Francisco Javier Rebolledo Muñoz
Decano del Medio Universitario Facultad de Ingeniería:
Padre Antonio José Sarmiento Nova S.J.
Director Carrera de Ingeniería de Sistemas:
Ingeniera Hilda Cristina Chaparro López
Director Departamento de Ingeniería de Sistemas:
Ingeniero Germán Alberto Chavarro Flórez
2
Nota de aceptación:
Director de Proyecto
Jurado
Jurado
Bogotá, Noviembre 2006
3
Artículo 23 de la Resolución No. 1 de Junio de 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en
sus proyectos de grado.
Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque
no contengan ataques o polémicas puramente personales. Antes bien, que se vean en
ellos el anhelo de buscar la verdad y la Justicia”
4
CONTENIDO
Pág.
1.
INTRODUCCIÓN ............................................................................................................................... 7
1.1.
DESCRIPCIÓN ............................................................................................................................. 7
1.2.
JUSTIFICACIÓN .......................................................................................................................... 7
1.3.
OBJETIVOS ................................................................................................................................... 7
1.3.1.
Objetivo general ............................................................................................................... 7
1.3.2.
Objetivos específicos. ..................................................................................................... 7
1.4.
ALCANCE ....................................................................................................................................... 8
1.5.
METODOLOGÍA ........................................................................................................................... 9
1.6.
ORGANIZACIÓN DEL DOCUMENTO. ................................................................................... 9
2.
PROBLEMÁTICA .............................................................................................................................. 11
2.1.
3.
PREGUNTAS DE INVESTIGACIÓN ...................................................................................... 12
MARCO TEÓRICO ........................................................................................................................... 13
3.1.
PKI ................................................................................................................................................. 13
3.1.1.
Conceptos generales ..................................................................................................... 13
3.1.2.
Que es una PKI ............................................................................................................... 14
3.1.3.
Componentes ................................................................................................................... 14
3.2.
SOA ............................................................................................................................................... 15
3.2.1.
Arquitectura y componentes generales de SOA [17] ....................................... 16
3.2.2.
Componentes funcionales de SOA [17] ................................................................. 17
3.2.3.
Características de SOA................................................................................................. 17
3.2.4.
Formas de lograr una Arquitectura Orientada a Servicios [18] ................... 18
3.3.
WEB SERVICES ......................................................................................................................... 19
3.3.1.
¿Por qué utilizar Web Services? ............................................................................... 19
3.3.2.
Valor competitivo de Web Services y SOA [23] ................................................. 20
3.4.
J2EE [34][35]........................................................................................................................... 21
3.4.1.
Soporte de J2EE a Web Services ............................................................................. 21
3.4.2.
API’s J2EE 1.4 ................................................................................................................. 22
3.4.3.
J2EE: Sistema Simplificado de integración .......................................................... 22
4.
ANÁLISIS PRELIMINAR ............................................................................................................. 24
4.1.
PKI DEL BANCO DE LA REPÚBLICA .................................................................................... 24
4.1.1.
Componentes ................................................................................................................... 25
4.2.
ENTRUST AUTHORITY PUBLIC-KEY INFRASTRUCTURE ............................................. 26
4.2.1.
Entrust Authority PKI [36][39] ................................................................................. 27
4.2.2.
Security Toolkit for the Java Platform [36] [37] ................................................ 27
4.2.2.1.
4.2.2.2.
4.2.2.3.
4.2.2.4.
5.
Arquitectura del Toolkit .................................................................................................... 27
Interoperabilidad ................................................................................................................. 36
Modularidad .......................................................................................................................... 37
Manejo de usuarios y credenciales............................................................................... 37
MODELO PROPUESTO ................................................................................................................. 43
5.1.
5.2.
5.3.
CONCEPTOS DE ARQUITECTURA Y MODELO ................................................................. 43
ARQUITECTURA PRELIMINAR .............................................................................................. 44
DISEÑO DEL MODELO [13][23][44] ................................................................................. 47
5
5.3.1.
5.3.1.1.
5.3.1.2.
5.4.
Detalle del modelo ......................................................................................................... 47
Java WSDP [45] .................................................................................................................. 48
Java API for XML-based RPC (JAX-RPC) ..................................................................... 49
IMPLEMENTACIÓN DEL MODELO ....................................................................................... 54
6. CASOS DE APLICACIÓN: TRANSFERENCIA DE FONDOS BANREP Y
APLICATIVO DE VERIFICACIÓN DE FIRMAS DIGITALES Y CONSULTA DE
TRANSACCIONES (VISOR) ................................................................................................................ 58
6.1.
ANÁLISIS .................................................................................................................................... 58
6.1.1.
Requerimientos funcionales y no funcionales ..................................................... 59
6.1.2.
Casos de Uso ................................................................................................................... 62
6.2.
DISEÑO ....................................................................................................................................... 62
6.2.1.
Arquitectura del caso de aplicación......................................................................... 62
6.2.2.
Modelo del caso de aplicación ................................................................................... 69
6.3.
HERRAMIENTA DE DESARROLLO ....................................................................................... 72
6.4.
IMPLEMENTACIÓN ................................................................................................................... 76
6.4.1.
Implementación Transferencia de Fondos Banrep ............................................ 77
6.4.2.
Implementación Visor .................................................................................................. 78
6.5.
CASOS DE PRUEBA .................................................................................................................. 79
6.5.1.
Transferencia de Fondos Banrep .............................................................................. 79
6.5.2.
Visor .................................................................................................................................... 82
7.
RESULTADOS FINALES ............................................................................................................... 84
8.
PROPUESTA PARA PROYECTOS FUTUROS ...................................................................... 87
LISTA DE FIGURAS ................................................................................................................................ 90
LISTA DE TABLAS ................................................................................................................................... 91
CONCLUSIONES ....................................................................................................................................... 92
BIBLIOGRAFÍA ......................................................................................................................................... 93
ANEXOS ........................................................................................................................................................ 97
ANEXO 1. CONCEPTOS GENERALES PARA ENTENDER QUE ES UNA PKI ....................................................... 97
ANEXO 2. CARACTERÍSTICAS DE SOA ...................................................................................................... 103
ANEXO 3. WEB SERVICES ......................................................................................................................... 104
ANEXO 4. PLATAFORMA J2EE .................................................................................................................. 124
ANEXO 5. DOCUMENTACIÓN DE CASOS DE USO ........................................................................................ 133
6
1. INTRODUCCIÓN
1.1. DESCRIPCIÓN
Este trabajo de grado busca proponer, desarrollar y aplicar un modelo que ponga a
disposición, por medio de Web Services, los servicios de una Infraestructura de Llaves
Públicas (PKI). Constituye la investigación, análisis, diseño, implementación, ejecución
de pruebas y elaboración de conclusiones, entre otras actividades realizadas, con el fin
de alcanzar los objetivos específicos planteados a continuación.
1.2. JUSTIFICACIÓN
El aumento en el uso de información electrónica y la necesidad de ofrecer seguridad en
su transmisión y manipulación, implica adoptar políticas y mecanismos que aseguren el
cumplimiento de los 7 principios de seguridad informática a saber: confidencialidad,
integridad, disponibilidad, autenticación, autorización, no repudio y observancia [51].
En una organización que cuenta con diferentes aplicaciones para el desarrollo de sus
funciones, y que necesita proteger su información electrónica, un sistema como PKI es
un mecanismo de seguridad a tener en cuenta, ya que permite cumplir con 4 de estos
principios: confidencialidad, integridad, autenticación y no repudio.
Es deseable que al adoptar una tecnología como PKI, todas las aplicaciones que
necesiten hacer uso de sus funcionalidades, lo puedan hacer de manera fácil y sin
demasiado desarrollo independiente. Con la nueva filosofía SOA, y los diferentes
estándares y protocolos que enmarca, esto puede ser posible a través de la publicación
de servicios.
Dentro de las ventajas de integrar una arquitectura orientada a servicios con un
sistema de seguridad como PKI, se encuentran la reutilización, integración
e
interoperabilidad de aplicaciones y el cumplimiento de los principios de seguridad de
integridad, confidencialidad, autenticación y no repudio.
1.3. OBJETIVOS
1.3.1.
Objetivo general
Diseñar e implementar un modelo orientado a servicios, haciendo uso de los protocolos
y estándares que enmarca la arquitectura SOA, para poner a disposición los servicios
de una infraestructura de llaves públicas (PKI).
1.3.2.
Objetivos específicos.
1. Investigar los protocolos y estándares ligados a los Web Services con el fin de
aplicarlos en el modelo propuesto.
7
2. Diseñar e implementar un modelo orientado a servicios haciendo uso de Web
Services, que permita poner a disposición al menos dos servicios1 ofrecidos por el
PKI Entrust utilizado en el Banco de la República.
3. Desarrollar un mecanismo de auditabilidad que permita registrar en una base de
datos las transacciones realizadas a través del modelo propuesto, con el fin de
llevar control de las acciones entre aplicaciones y los servicios del sistema PKI.
4. Diseñar e implementar un aplicativo que permita verificar firmas digitales y
consultar las transacciones realizadas a través del modelo propuesto, con el fin de
verificar la funcionalidad del mecanismo de auditabilidad.
5. Desarrollar un aplicativo ejemplo que acceda a las funcionalidades del PKI a través
del modelo implementado.
1.4. ALCANCE
El alcance del presente trabajo de grado es proponer un modelo para que las
aplicaciones puedan hacer uso de las funcionalidades del PKI a través de Web Services,
y comprobarlo implementando una aplicación que cumpla con requerimientos que
pueden darse en una entidad bancaria.
Adicionalmente, haciendo uso del modelo, implementar una aplicación que sirva como
sustento para temas probatorios de identidad digital ante entidades jurídicas.
A continuación se listan los resultados esperados.
Resultados esperados:
- Documento de investigación y análisis de Web Services junto con sus estándares
y protocolos.
- Modelo
basado en SOA que ponga a disposición servicios del PKI del producto
Entrust.
- Implementación del
modelo (software) que pone a disposición algunos servicios
del PKI Entrust.
- Mecanismo
de auditabilidad implementado a través de Web Services, que
permita registrar en una base de datos los eventos 2 que ocurran en las
aplicaciones que hagan uso del PKI.
- Adaptación o construcción de un aplicativo que haga uso del modelo propuesto.
Posibles servicios: Cifrado, Descifrado, Firma Digital o Verificación de Firma.
Los eventos son propios de la aplicación. Ejemplo: en una aplicación de Transferencia de Fondos un evento
es consignación.
1
2
8
- Aplicativo
tipo visor que permita consultar los eventos registrados y además
permita la validación de la firma de una transacción.
- Base
de datos que almacene los eventos registrados por el mecanismo de
auditabilidad.
Este trabajo de grado es un ejercicio de investigación verificado y será la base para la
implementación que haga el Banco de la República para poner a disposición los
servicios del PKI.
1.5. METODOLOGÍA
Este proyecto de grado dividió en dos fases fundamentales. La primera es la fase de
investigación para la cual se hizo uso de una metodología exploratoria y la segunda es
la fase de desarrollo para lo cual se hizo uso de la metodología RUP3 Simplificado.
Metodología exploratoria: Se utilizó por tratarse de un tema inicialmente novedoso,
poco explorado y desconocido por los autores de este documento. Esta metodología
permitió obtener un análisis preliminar de la situación con un mínimo de costo y
tiempo. La metodología tuvo dos partes:
- Revisión de la literatura
- Construcción del marco teórico.
Metodología RUP simplificado: Se utilizó esta metodología, que es una variación de
RUP de IBM4, por tratarse de un proyecto con un desarrollo pequeño. Esta metodología
ofrece las bondades de un RUP completo pero permite aplicarse a proyectos poco
complejos y de corta duración.
Cada iteración para el caso de este proyecto de grado comprende:
- Planificar la iteración (estudio de riesgos)
- Análisis
- Diseño
- Implementación
- Evaluación del avance de la iteración
- Preparación de la entrega
1.6. ORGANIZACIÓN DEL DOCUMENTO.
3
4
RUP: Rational Unified Process.
RUP de IBM http://www-306.ibm.com/software/awdtools/rup/
9
Este documento se organiza en ocho capítulos que se describen a continuación de
manera general.
El capítulo dos hace referencia a la problemática a la cual nos enfrentamos y a la
oportunidad que tenemos de resolverla.
El capítulo tres contempla todos los temas y conceptos necesarios para un adecuado
entendimiento de lo alcanzado y desarrollado en este trabajo de grado. Se tratan
temas como PKI (Infraestructuras de Llaves Públicas), qué es y cémo se compone,
utilidad, características y componentes de una arquitectura SOA, componentes y
ventajas de los Web Services y su relación con SOA, J2EE, entre otros.
El capítulo cuatro comprende el Análisis preliminar que se realizó para alcanzar los
resultados esperados. Contempla la descripción del PKI del Banco de la República,
detallando su arquitectura, principales funciones, características y utilidades.
El capítulo cinco describe el modelo que se propone para poner a disposición los
servicios del PKI del Banco de la Republica a través de Web Services. Comprende la
Arquitectura base para el diseño del modelo a implementar y el detalle de cada parte
del modelo.
El capítulo seis presenta el análisis, diseño, implementación y pruebas de un caso de
aplicación que haga uso del modelo propuesto. Se contempla la evaluación de
herramientas de desarrollo disponibles en el mercado para llevar a cabo la
implementación y la selección de una de ellas para su posterior utilización.
El capítulo siete compara los resultados obtenidos contra los resultados esperados
relacionando cada uno de ellos con los objetivos general y específicos.
El capítulo ocho contempla la propuesta para proyectos futuros en donde se establecen
algunas formas de darle continuidad o mejora al presente trabajo.
Por último se plantean las conclusiones obtenidas del desarrollo de este trabajo de
grado y se presentan como anexos la teoría de Web services, la documentación de los
casos de uso entre otros.
10
2. PROBLEMÁTICA
La mayoría de organizaciones cuenta con diferentes aplicaciones que requieren
transmitir y manipular información electrónica de forma segura. Para garantizar
autenticidad, no repudio, confidencialidad e integridad de la información que manejan
estas aplicaciones, se puede hacer uso de tecnologías de seguridad tales como IPSec,
SSL, S/MIME, PKI, entre otras.
El Banco de la República, que para nuestro caso es la organización en donde se lleva a
cabo este trabajo de grado, hace uso de un PKI comercial a través del cual presta a
sus usuarios 5 servicios de firma digital, verificación de firma, ciframiento,
desciframiento, entre otros.
Actualmente cada aplicativo tiene su forma de acceder a las funcionalidades del PKI, es
decir, cada uno tiene un desarrollo independiente y complicado que le permite hacer
uso del PKI. Esto se convierte en un esquema ineficiente debido al gran número de
implementaciones y adaptaciones diferentes que hay que hacer por cada aplicativo.
La oportunidad que se presenta, es hacer uso de la arquitectura orientada a servicios,
para proponer e implementar un modelo que permita a las aplicaciones la reutilización
y fácil acceso a los servicios de seguridad ofrecidos por el PKI.
Este planteamiento, a parte de tener las bondades que ofrece una arquitectura
orientada a servicios, tiene como beneficio que:
- Un desarrollador no necesita conocer como funciona la PKI del Banco para hacer
uso de sus funcionalidades, simplemente debe saber como invocar los servicios
PKI que quiera utilizar en su aplicación.
- Se reduce la complejidad en el desarrollo de aplicaciones que deban hacer uso de
las funcionalidades del PKI, ya que una aplicación se limitaría a invocar servicios.
- Se establece una forma estándar de incluir seguridad en las aplicaciones ya que
todas las aplicaciones harían uso de los mismos servicios del PKI.
Adicionalmente, el PKI del Banco de la República no cuenta con un mecanismo de
auditabilidad central, que indique los detalles de una operación firmada digitalmente y
que permita verificar los datos del firmante. Por ejemplo, si un usuario realiza una
operación en una aplicación y la firma digitalmente, un ente externo, una entidad
jurídica o auditora, interesada en los detalles de dicha operación, no tiene forma de
saberlos. Para solucionar esto se propone:
5
Usuarios: Personas internas o externas que hacen uso de las aplicaciones del Banco de la República.
11
- La
implementación de un mecanismo de auditabilidad que registre en un
repositorio central las operaciones que se realizan en una aplicación, firmadas
digitalmente.
- La
implementación de un aplicativo que permita consultar las operaciones
firmadas digitalmente y verificar la identidad del ente que llevo a cabo una
operación.
2.1. PREGUNTAS DE INVESTIGACIÓN
En el transcurso del desarrollo del documento el lector podrá encontrar respuesta a
preguntas como:
1. ¿Puede una estrategia SOA contribuir a una organización en el manejo de
evidencias digitales en el tiempo?
2. ¿Es suficiente el modelo de firma digital ofrecido por las herramientas de
PKI existentes, para contribuir de manera significativa al manejo de la
evidencia digital?
3. Existen arquitecturas y/o modelos sencillos en su utilización en los que una
organización se pueda basar para implementar una estrategia de servicios
PKI vía SOA?
4. ¿Qué es y cuales son los componentes de una PKI?
5. ¿Qué es y por qué utilizar SOA?
6. ¿Son los Web Services una forma valida de implementar una Arquitectura
Orientada a Servicios?
7. ¿Qué ventajas ofrecen los Web Services ante otras tecnologías existentes
para implementar una SOA?
8. ¿Qué ventaja tiene para una organización hacer uso de una PKI a través de
SOA?
9. ¿Por qué en seguridad informática es necesario un mecanismo de
auditabilidad?
10. ¿Qué ofrece la arquitectura J2EE para implementar una estrategia SOA?
12
3. MARCO TEÓRICO
Este capítulo tiene como fin presentar los temas y conceptos que fueron necesarios
explorar para lograr los objetivos propuestos. Pretende contextualizar al lector en la
temática que abarca el presente trabajo de grado y crear un lenguaje común entre el
lector y los autores de este documento ya que la terminología y definiciones aquí
presentadas se utilizan lo largo del texto.
Dado que los temas fuertes que comprende el objetivo principal de este trabajo de
grado son PKI, SOA y Web Services, existe este capítulo dedicado a aclarar y
profundizar en los aspectos más importantes que estos tópicos abarcan, para poder
entender el desarrollo planteado en capítulos posteriores.
De una PKI es importante conocer qué es, sobre qué principios se fundamenta y cuales
son sus componentes, lo cual es presentado en el numeral 3.1.
De SOA es necesario entender que constituye la base para cualquier estrategia
orientada a servicios que se quiera implementar en una organización. Para esto, en el
numeral 3.2, se abordan sus componentes, los cuales existen en cualquier tipo de
implementación específica que se haga de SOA, y se mencionan, sin entrar en detalle,
algunas tecnologías existentes para lograr una arquitectura orientada a servicios,
dentro de las que se encuentra Web services, tecnología por la cual se optó en este
trabajo de grado para llevar acabo SOA.
Finalmente, como es de esperarse, se incluye el numeral 3.3 dedicado a Web services,
en donde se expone qué son, cuáles son sus componentes, cómo se relaciona con
SOA, cuáles son los protocolos y estándares que habilitan su funcionamiento y por qué
hacer uso de ellos.
Lo contenido en este capítulo representa el sustento teórico de los hallazgos y
resultados obtenidos en este trabajo de grado.
3.1. PKI
3.1.1.
Conceptos generales
Para abordar y comprender mas adelante lo que es una infraestructura de llaves
públicas, es necesario tratar algunos conceptos relacionados directamente con su
definición.
13
En el Anexo 1 se encuentra el detalle de estos conceptos generales en donde primero
se habla de lo que es una criptografía de clave pública y sus principales aplicaciones,
para luego tratar los certificados digitales.
Referirse al Anexo 1 “Conceptos generales para entender que es una PKI”.
3.1.2.
Que es una PKI
Varias definiciones se encuentran en diferentes fuentes bibliográfícas acerca de lo que
es una PKI, pero todas estas convergen a definir una infraestructura de llaves públicas
como una infraestructura de seguridad basada en criptografía de clave pública, que a
través del conjunto de componentes y políticas que la conforman, gestiona claves,
certificados digitales y ofrece servicios de firma digital y ciframiento, permitiendo
obtener autenticación, integridad, no repudio y confiabilidad en el intercambio de
información electrónica sensible, ya sea en intranets, extranets o Internet [1] [3] [28].
3.1.3.
Componentes
Con respecto a los componentes de una infraestructura de llaves publicas, estos
pueden variar de una implementación a otra, pero siempre van a estar presentes
algunos componentes básicos para que el PKI cumpla su función (Figura 1).
- CA
(Certification Authority): Autoridad certificadora que proporciona la base de
confianza en la PKI [28]. Su función es crear y emitir certificados a todos los
usuarios aceptados por las Autoridades de Registro dependientes de ella,
firmarlos y almacenarlos en un repositorio de acceso público. Dentro de sus
tareas también se encuentra mantener actualizada periódicamente una lista de
revocación de certificados [1] [13]. La AC es también conocida como la tercera
parte confiable (Trusted Third Party o TTP) [4].
- RA
(Registration Authority): Autoridad de registro cuya labor es verificar la
identidad de los solicitantes de certificados para ordenar a la autoridad
certificadora expedirlos [13]. Es el punto de comunicación entre los usuarios de
la PKI y la autoridad certificadora [28].
- Repositorio: Lugar en donde se almacenan los certificados y listas de revocación
(Certificate Revocation List o CRL). La CRL es una lista, firmada digitalmente, de
certificados revocados que no han expirado. Los usuarios pueden consultar esta
lista por diferentes medios como correo electrónico, Web o LDAP (Lightweight
Directory Access Protocol), para asegurarse de que un determinado certificado
sigue siendo válido justo en ese momento [5].
- Certificate
holder, entidad cuyos datos personales están asociados a su clave
pública en un certificado digital [5].
14
- Relaying
Party, entidad que confía en el contenido de un certificado por estar
este firmado por una CA de confianza [5].
3.2. SOA
SOA (Service-Oriented Architecture) es un estilo de arquitectura de Tecnología de
información (TI), que soporta la orientación a servicios. Este enfoque permite diseñar y
construir soluciones de software interoperables ya que se basa en la independencia de
plataformas de hardware, sistemas operativos y lenguajes de programación.
Básicamente una arquitectura orientada a servicios es una colección de servicios que
se comunican entre ellos. La comunicación puede involucrar simplemente el paso de
datos o la coordinación de alguna actividad entre varios servicios [8].
Cada servicio se encargaría de exponer una funcionalidad bien definida a cualquier
aplicación que la requiera. De esta manera, una aplicación final simplemente orquesta
la ejecución de un conjunto de estos servicios, añade su lógica particular y le presenta
una interfaz al usuario final (Figura 2) [9].
Figura 1. Componentes de una PKI.
15
Figura 2. Un sistema sencillo basado en servicios.
Exponer procesos de negocio como servicios es la clave de la flexibilidad de la
arquitectura. Esto permite que otras piezas de funcionalidad (incluso también
implementadas como servicios) hagan uso de otros servicios de manera natural, sin
importar su ubicación física. Así un sistema evoluciona con la adición de nuevos
servicios y su mejoramiento, donde cada servicio evoluciona de una manera
independiente.
Una Arquitectura Orientada a Servicios final, define los servicios de los cuales estará
compuesto el sistema, sus interacciones y con que tecnologías serán implementados.
3.2.1. Arquitectura y componentes generales de SOA [17]
SOA esta basado en la interacción de tres componentes: un proveedor (provider), un
registro (registry) y un consumidor (requestor). La interacción entre estos
componentes implica publicar información respecto a un servicio, encontrar que
servicios están disponibles, y poder interactuar con los mismos (ver Figura 3).
En un escenario típico, un proveedor almacena la implementación de los servicios. El
proveedor define las descripciones de los servicios y es el encargado de publicarlas en
un registro. El consumidor utiliza el registro para encontrar la descripción de un
servicio que desea utiliza. Una vez obtenida la descripción del servicio el consumidor
puede interactuar (hacer uso) del servicio.
A continuación, en la Tabla 1, se describen los componentes generales de SOA.
Componente
Consumidor
(Requestor)
Proveedor
(Provider)
Registro
(Registry)
Contrato
(Service
Contract)
Descripción
Es una aplicación, servicio, o algún otro tipo de software que
requiera un servicio. Es la entidad que inicia la localización de un
servicio en el registro (obtención del contrato), y se enlaza con el
mismo por medio de unos componentes de Trasporte para poder
acceder y ejecutar determinadas funciones.
El consumidor de servicios ejecuta el servicio enviando solicitudes
en un formato acorde al contrato obtenido.
Es el servicio, o entidad direccionable que acepta y ejecuta
solicitudes provenientes de los consumidores. Puede ser un
mainframe, un componente, o algún tipo de sistema de software
que efectué la correspondiente solicitud. El proveedor de servicio
publica su contrato en el registro para que pueda ser accedido por
el consumidor de servicios.
Es un directorio que contiene servicios disponibles. Es una entidad
que acepta y almacena contratos de proveedores y facilita estos
contratos a los consumidores interesados.
Es una especificación de la forma en que un consumidor de
servicios va a interactuar con el proveedor de servicios. El contrato
especifica el formato de las solicitudes y de las respuestas por parte
del servicio. Un contrato puede requerir una serie de precondiciones
y poscondiciones, las cuales indican el estado en que debe estar un
16
servicio para poder ejecutar una función particular. El contrato
también especifica los niveles de calidad del servicio (quality of
service (QoS)).
Tabla 1. Componentes generales de SOA.
Figura 3. Interacción entre los componentes generales de SOA.
3.2.2.
Componentes funcionales de SOA [17]
Adicional a los componentes generales previamente nombrados, los sistemas basados
en una arquitectura SOA poseen tres componentes funcionales que se detallan en la
Tabla 2.
Componente
Transporte
(Transport)
Descripción
(Description)
Descubrimiento
(Discovery)
3.2.3.
Descripción
Representa los formatos y protocolos utilizados para comunicarse
con un servicio.
Representa el lenguaje utilizado para describir un servicio.
Provee la información necesaria para poder disponer de un
servicio. Como mínimo, un lenguaje descriptivo otorga los
recursos para especificar el contrato del servicio, incluyendo las
operaciones que este puede efectuar y los parámetros o
formatos del mensaje que puede intercambiar.
Representa el mecanismo utilizado para registrar o anunciar un
servicio y encontrar un servicio con su correspondiente
descripción.
Tabla 2. Componentes funcionales de SOA.
Características de SOA
17
SOA es una forma de arquitectura para sistemas distribuidos caracterizada por las
siguientes propiedades:
- Vista lógica
- Orientación a Mensajes
- Orientación a la descripción.
- Granularidad.
- Orientación a la red.
- Neutral a la plataforma.
- Localización transparente.
En el Anexo 2 “Características de SOA” se encuentra el detalle de cada una de estas
propiedades.
3.2.4.
Formas de lograr una Arquitectura Orientada a Servicios [18]
El concepto detrás de los sistemas orientados a servicios no es algo nuevo. Varios
estándares computacionales distribuidos (middlewares) existentes implementan SOA.
Ejemplo de estos son:
-
Java RMI: Java Remote Method Invocation.
CORBA: Common Object Request Broker Architecture.
DCE: Distributed Computing Environment.
DCOM: Distributed Component Object Model.
Cada implementación define una serie de formatos y protocolos que representan los
componentes de SOA. La tabla 3 muestra los protocolos y estándares que representan
los componentes de SOA en cada tecnología.
Mecanismo de
invocación
Formato de los
datos
Formato de
interacción
Protocolo de
Java RMI6
Java RMI
CORBA7
CORBA RMI
DCE8
RPC
Web Services
JAX-RPC, .NET,
Serialized
Java
Stream
CDR
NDR
XML9
GIOP
PDU
SOAP10
JRMP
IIOP
RPC CO
HTTP, SMTP, …
6
JRMP = Java Remote Method Protocol.
ORB = Object Request Broker. CDR = Common Data Representation. GIOP = General Inter-ORB Protocol.
IIOP= Internet Inter-ORB Protocol. IDL = Interface Definition Language. COS = CORBA Object Services.
8
RPC = Remote Procedure Call. NDR = Network Data Representation. PDU = Protocol Data Units. RPC CO
= RPC Connect-Oriented protocol. IDL = Interface Definition Language. CDS = Cell Directory Service.
9
Extensible Markup Language 1.0, W3C Recommendation: http://www.w3.org/TR/REC-xml.
10
SOAP 1.2 Part 1, W3C Working Draft: http://www.w3.org/TR/soap12-part1/
7
18
transferencia
Descripción de
la interfaz
Mecanismos de
descubrimiento
Java
Interface
Java Registry
CORBA IDL
DCE IDL
WSDL11
COS naming
CDS
UDDI12
Tabla 3. Relación de componentes de SOA con tecnologías distribuidas.
No es propósito de este documento de investigación entrar en detalle respecto a los
diferentes estándares y mecanismos que implementan SOA, pero sí justificar por que
se optó por el uso de Web services para el desarrollo de este trabajo de grado y
profundizar en sus componentes y funcionamiento. Para tal fin, a continuación en el
numeral 3.3, se trata en profundidad los Web Services y se exponen las ventajas de
utilizarlos.
3.3. WEB SERVICES
Toda la temática referente a Web Services se encuentra en el Anexo 3 “Web services”
de este documento.
Este anexo tiene como fin dar cumplimiento al objetivo específico 1 enunciado en el
numeral 1.3.2, donde se planea investigar a profundidad los Web Services junto con
los protocolos y estándares que estos enmarcan.
Se recomienda al lector que si no está familiarizado con los Web Services y sus
estándares recurra al Anexo 3 donde podrá encontrar:
-
Qué son los Web Services.
Cuáles son los componentes generales y funcionales de los Web Services.
Cuáles son los escenarios de implementación de los Web Services.
Arquitectura y estándares de los Web Services.
3.3.1.
¿Por qué utilizar Web Services?
La aparición de los Web Services introduce un nuevo paradigma para facilitar el
intercambio de información a través de Internet basado en estándares de Internet
abiertos y tecnologías existentes. Haciendo uso de los estándares de la industria, los
Web Services encapsulan aplicaciones y las publican como servicios. Estos servicios
entregan información en formato XML y la ponen a disposición para su uso en Internet,
siendo posible localizarla dinámicamente, y accederla utilizando un amplio número de
plataformas computacionales, dispositivos móviles, y demás.
Debido a la flexibilidad de usar estándares y protocolos abiertos, facilita la integración
de aplicaciones empresariales (EIA 13 ), integración business-to-business (B2B), y
comunicación a través de Internet e intranets corporativas A2A 14.
11
Web Services Description Language 1.1, W3C Note: http://www.w3.org/TR/wsdl
Universal Description, Discovery and Integration specifications: http://www.uddi.org/specification.html
13
EIA: Enterprise Application Integration.
12
19
En organizaciones con aplicaciones heterogéneas y arquitecturas distribuidas la
introducción de Web Services estandariza los mecanismos de comunicación y habilita
la interoperabilidad de aplicaciones basadas en diferentes lenguajes de programación y
residentes en diferentes plataformas.
Hoy en día, los líderes en tecnología han puesto sus estrategias alrededor de proveer
soluciones de infraestructura para el uso de Web Services. Con la creciente adopción,
aceptación y disponibilidad de plataformas, lenguajes, herramientas, y soluciones de
soporte tecnológicas, los Web Services se convertirán en un nuevo servicio de la
industria proveyendo estrategias de negocios a través de Internet.
Beneficios de Web services sobre otras tecnologías [32]
Los web services presentan algunas diferencias sobre sistemas distribuidos
tradicionales, tales como EJB15, COM/DCOM16, CORBA, SOM/DSOM17 o DCE18. Algunas
de las diferencias son las siguientes (Algunas diferencias sólo afectan a algunos
sistemas, no a todos):
- Escaso acoplamiento. El cliente no necesita conocer nada acerca de la
implementación del servicio al que está accediendo, salvo la definición WSDL
- Independencia del lenguaje de programación. El servidor y el cliente no necesitan
estar escritos en el mismo lenguaje
- Independencia del modo de transporte. SOAP puede funcionar sobre múltiples
protocolos de transporte, como por ejemplo HTTP, HTTPS 19 , HTTP-R 20 , BEEP 21 ,
JABBER22, IIOP23, SMTP24 o FTP25.
- Múltiples modos de invocación. Los servicios web soportan tanto invocación estática
como invocación dinámica.
- Múltiples estilos de comunicación. Los servicios web soportan tanto comunicación
síncrona (RPC) como comunicación asíncrona (mensajería).
- Extensibilidad. Al estar basados en XML, los servicios web son fáciles de adaptar,
extender y personalizar.
3.3.2.
Valor competitivo de Web Services y SOA [23]
14
A2A: application-to-application.
EJB: Enterprise JavaBeans.
16
DCOM:Distributed Component Object Model.
17
DSOM: Distributed System Object Model.
18
DCE: Distributed Computing Environment.
19
HTTPS: Hypertext Transfer Protocol over Secure Socket Layer.
20
HTTP-R: Reliable HTTP.
21
BEEP: Blocks Extensible Exchange Protocol
22
Jabber es un protocolo libre basado en el estándar XML para mensajería instantánea. El protocolo esta
gestionado por Jabber Software Foundation http://www.jabber.org/jsf/.
23
IIOP: Internet InterORB Protocol.
24
SMTP: Simple Mail Transfer Protocol.
25
FTP: File Transfer Protocol.
15
20
Los negocios que implementan exitosamente SOA están destinados a tener una
ventaja competitiva con respecto a aquellos que no, por que quienes tienen servicios
alineados con estrategias de tecnología de información (TI) pueden reaccionar más
rápidamente a requerimientos de negocios cambiantes, que aquellos con sistemas de
tecnología de información alineados a un ambiente de ejecución particular.
Es más fácil combinar Web Services, cambiarlos, cambiar su composición, y mas
barato modificarlos junto con los datos XML utilizados, que cambiar todo un ambiente
de ejecución. Las ventajas y beneficios de SOA con Web Services incluyen un mejor
retorno de inversión para el gasto en proyectos de integración tecnológica, un tiempo
menor para ver resultados al llevar a cabo proyectos, y la habilidad para responder
más rápidamente a mercados cambiantes y requerimientos gubernamentales.
El uso de Web services SOA para integración, manejo de procesos de negocio y acceso
multicanal, facilita a las empresas la creación de ambientes de integración tecnológica
más estratégicos y un ambiente más cercano a las características operacionales y
propósitos del negocio.
3.4. J2EE26 [34][35]
Este apartado se incluye dado que el caso de aplicación planteado en el capítulo 6 está
basado en la plataforma J2EE.
Toda la temática de J2EE se encuentra en el Anexo 4 “Plataforma J2EE”. Se
recomienda al lector que si no está familiarizado con la arquitectura J2EE recurra al
Anexo 4 donde podrá encontrar:
-
Introducción a J2EE.
Componentes de J2EE.
Contenedores J2EE.
Tecnologías J2EE.
3.4.1.
Soporte de J2EE a Web Services
Los servicios Web (Web Services) son aplicaciones empresariales basadas en Web que
utilizan estándares abiertos soportados en XML y protocolos de transporte para
intercambiar información con clientes que hacen llamados a estos servicios. La
plataforma J2EE provee las herramientas y los API’s XML necesarios para un rápido
diseño, desarrollo, prueba y despliegue de servicios Web, clientes que puedan
interactuar completamente con otros servicios Web residentes en plataformas basadas
o no basadas en Java.
Al desarrollar clientes y servicios Web haciendo uso de los API’s XML y J2EE,
simplemente se pasan datos como parámetros a los métodos que efectúan los
llamados y se procesa la información recibida. No es necesario encargarse de los
aspectos de programación de bajo nivel ya que el API XML se encarga de traducir la
26
J2EE: Java 2 Enterprise Edition.
21
información de la aplicación hacia y desde formatos XML que son enviados a través de
los protocolos estandarizados de transporte basados en XML.
La traducción de la información a formatos estandarizados basados en XML es lo que
hace a los clientes y servicios Web desarrollados con los API’s XML y J2EE
completamente interoperables. Esto no necesariamente significa que la única
información transportada son tags XML, ya que también puede ser texto plano, o
cualquier tipo de información binaria como audio, video, mapas, archivos, etc.
3.4.2.
API’s J2EE 1.4
La Figura 4 muestra la disponibilidad de los API’s de la plataforma J2EE 1.4 en cada
tipo de contenedor.
Figura 4. API’s plataforma J2EE.
Para mas detalle de algunos APIs J2EE ver Anexo 4.
3.4.3.
J2EE: Sistema Simplificado de integración
La plataforma J2EE es un sistema de integración de soluciones independiente de la
plataforma, que abre las puertas a un mercado en el cual los vendedores pueden
dirigir sus productos a cualquier tipo de comprador. Este nuevo mercado encamina a
los vendedores a competir con productos y servicios que beneficien a los compradores,
productos con mejor desempeño, mejores herramientas y mejor soporte al cliente.
22
El API J2EE brinda integración a las aplicaciones y a los sistemas a través de:
- Un modelo de aplicación unificado a través de capas y enterprise beans.
- Mecanismo de solicitud – respuesta simplificado por medio de paginas JSP y
Servlets.
- Modelos de seguridad confiable a través de JAAS27.
- Integración de intercambio de datos basados en XML haciendo uso de JAXP 28 ,
SAAJ29, y JAX-RPC30.
- Interoperabilidad simplificada a través de la arquitectura de conectores J2EE.
- Fácil acceso a bases de datos por medio de JDBC31.
- Integración de aplicaciones empresariales a través de JMS 32 , JTA 33 , message –
driven beans y JNDI34.
27
JAAS: Java Authentication and Authorization Service.
JAXP: Java API for XML Processing.
29
SAAJ: SOAP with Attachments API for Java.
30
JAX-RPC: Java API for XML-based RPC.
31
JDBC: Java Database Connectivity.
32
JMS: Java Message Service.
33
JTA: Java Transaction API.
34
JNDI: Java Naming and Directory Interface.
28
23
4. ANÁLISIS PRELIMINAR
Este capítulo comprende el análisis previo que fue necesario realizar para poder
diseñar e implementar el modelo orientado a servicios que permite poner a disposición
los servicios ofrecidos por el PKI utilizado en el Banco de la República, que se plantea
en el objetivo específico 2 descrito en el numeral 1.3.2.
Abarca el PKI del Banco de la República y el producto comercial adoptado por esta
organización para ofrecer funciones PKI.
Para poder lograr el planteamiento de un modelo que ofreciera funcionalidades de una
PKI a través de una arquitectura orientada a servicios, que es lo que se busca con
este trabajo de grado , fue necesario explorar una herramienta comercial PKI. Todos
los numerales incluidos en este capítulo pretenden mostrar la complejidad que hay
detrás de algunas funcionalidades de una PKI comercial para luego, en el capítulo 5,
ver como a través de un modelo orientado a servicios se pueden ocultar y encapsular
estas complejidades, eximiendo a un desarrollador de lidiar con un código enredado
cuando quiera hacer uso las funcionalidades de una PKI, y limitando el desarrollo de
una aplicación a una simple invocación de servicios.
Lo aquí contenido, junto con el marco teórico expuesto en el capitulo 3, constituyen la
base teórica y conceptual del modelo propuesto que se detalla en el capitulo 5 del
presente documento.
4.1. PKI DEL BANCO DE LA REPÚBLICA
Esta sección se incluye dada la necesidad de conocer como está conformada e
implantada la PKI del Banco de la República, pues parte del desarrollo de este trabajo
de grado tiene que ver con su funcionamiento y componentes.
El Banco de la República, adquirió y monto un sistema PKI en el año 2003, con el fin
de elevar el nivel de seguridad de los servicios electrónicos que ofrece y alinearse con
la legislación colombiana vigente en lo referente a mensajes de datos, comercio
electrónico y firma digital [7].
A continuación, en el numeral 4.1.1, se describen los elementos que conforman dicha
PKI.
24
4.1.1.
Componentes
La PKI del Banco, aunque esté montada con un producto específico, cuenta con los
componentes comunes a cualquier PKI los cuales fueron tratados en el numeral 3.1.3
del presente documento.
En su visión más general la PKI del Banco tiene los siguientes componentes:
- CA35 Banrep: Es la Entidad de Certificación Cerrada del Banco de la República.
- Repositorio/Directorio: Es el lugar donde la CA Banrep publica los certificados
digitales de todos sus suscriptores junto con la CRL. Actualmente el protocolo de
acceso al directorio es LDAP36 versión 3.

CRL 37 : Es un certificado firmado digitalmente por la CA Banrep que
contiene los certificados que han perdido validez por algún uso indebido o
porque su vigencia caducó. La CRL, como cualquier certificado, tiene una
vigencia y es publicada en el repositorio para ser consultada por los
usuarios de la CA Banrep.
- Autoridad de Registro (RA38): Su labor es verificar y validar la información de los
usuarios/suscriptores de la CA Banrep.
- Suscriptor: Usuario de la CA BANREP que tiene certificados asignados.
- Usuario: Persona que puede verificar un documento firmado pero no tiene
certificados asignados.
- Declaración de prácticas de Certificación (DPC): define las reglas con las cuales las
llaves y certificados de verificación de firma y encripción serán generados y
administrados dentro de la CA BANREP, y los demás procesos y procedimientos que
se deben cumplir dentro de su operación [7].
La interacción típica entre los componentes del PKI se muestra en la Figura 5.
Proceso de Solicitud de un Certificado
La interacción entre los componentes de la PKI en un proceso de solicitud de
certificado digital esta dada en los siguientes pasos:
1. El suscriptor que quiera obtener un certificado digital expedido por la CA
Banrep, genera un par de llaves con un provider, que para el caso del Banco de
la Republica es Entrust.
2. El suscriptor envía a la RA el par de llaves e información de su identidad.
35
CA: Certification Authority.
LDAP son las siglas de Lightweight Directory Access Protocol, protocolo ligero para acceder al servicio de
directorio.
37
CRL: Certificate Revocation List.
38
RA: Registration Authority.
36
25
3. La RA verifica y valida los datos enviados por el suscriptor y arma la estructura
X.509 39 del certificado.
4. La RA envía la estructura X.509 a la CA Banrep.
5. La CA Banrep firma el certificado digital.
6. La CA Banrep publica el certificado digital en el directorio.
7. La CA Banrep envía el certificado digital al suscriptor.
Figura 5. Componentes PKI Banrep.
4.2. ENTRUST AUTHORITY PUBLIC-KEY INFRASTRUCTURE
Entrust Authority PKI, en su versión 6, es el producto comercial utilizado por el Banco
de la República para ofrecer funciones PKI a los usuarios internos y externos de la
organización que realizan intercambios electrónicos.
Para efectos de este trabajo de grado, es necesario revisar y entender algunos
conceptos y características propias de este producto, que juegan un papel importante
en el diseño e implementación del modelo propuesto especificado en el capitulo 5.
A continuación se presentan y describen algunos aspectos alrededor de este producto
comercial.
X.509 es un estándar que especifica, entre otras cosas, formatos estándar para certificados de claves
públicas.
39
26
4.2.1.
Entrust Authority PKI [36][39]
Manejando el ciclo de vida completo de identidades digitales basadas en certificados
digitales, y ofreciendo servicios de administración de llaves y certificados, Entrust
Authority PKI ofrece capacidades de ciframiento, firma digital y autenticación para ser
consistente y transparentemente aplicadas sobre un amplio rango de aplicaciones y
plataformas.
Este producto comercial consiste, entre otras cosas, de una serie de Toolkits para
ayudar a los desarrolladores a construir aplicaciones que tomen ventaja de las
operaciones criptográficas en una infraestructura de llaves públicas. Permiten
desarrollar y construir aplicaciones, que protegen la privacidad, integridad y
autenticidad de la información trasmitida entre estaciones de trabajo y servidores de
una red, cuya seguridad es manejada con un PKI.
Entrust Authority PKI, cuenta con Toolkits para varios lenguajes de programación
entre los que se encuentran C, C++ y Java. Para efectos de este trabajo de grado se
optó por hacer uso del Toolkit para Java denominado Security Toolkit for the Java®
Platform. A continuación, en el numeral 4.2.2, se establecen sus detalles.
4.2.2.
Security Toolkit for the Java Platform [36] [37]
Esta sección presenta información acerca de cómo está organizado el Toolkit de
Entrust para Java, exponiendo su arquitectura y algunas de sus características y
funcionalidades utilizadas en el modelo propuesto especificado en el capítulo 5.
4.2.2.1. Arquitectura del Toolkit
El Toolkit ofrece APIs40 tanto en alto como bajo nivel que permiten a una aplicación
Java ejecutar tareas relacionadas con seguridad. Java Security 41 es la colección de
APIs sobre la que se fundamenta el Toolkit y provee la base para sus servicios
criptográficos. Estos APIs incluyen los paquetes de seguridad del J2SDK 42, la JCE (Java
Cryptography Extensión) y el JSSE43.
En la Figura 6 se presenta la arquitectura del Toolkit mostrando los componentes que
la conforman e interacción entre ellos.
JCA44 [40] [42]
El Toolkit se a adhiere a la Arquitectura Criptográfica de Java (JCA) y complementa
esta con mas algoritmos criptográficos.
40
API: Application Programming Interfaces.
El API de seguridad de Java esta conformado por el paquete java.security y sus subpaquetes.
42
J2SDK: Java 2 Software Development Kit.
43
JSSE :Secure Sockets Extensión.
41
44
JCA: Java Cryptography Architecture http://java.sun.com/security/.
27
La JCA es un marco de trabajo para acceder y desarrollar funciones criptográficas en la
plataforma Java. Se diseñó alrededor de dos principios básicos:
- Independencia e interoperabilidad de las implementaciones.
- Independencia y extensibilidad de los algoritmos.
La JCA define algunos términos básicos que vale la pena aclarar:
Figura 6. Arquitectura básica del “Security Toolkit for Java".
 Motor
En el contexto de la JCA se utiliza el término motor (engine) para referirse a
una representación abstracta de un servicio criptográfico que no tiene una
implementación concreta.
 Algoritmo
Un algoritmo es una implementación de un motor. P. ej. el algoritmo MD5 45
es una implementación del motor de algoritmos de resumen de mensajes.
 Proveedor
Un proveedor es el encargado de proporcionar la implementación de uno o
varios algoritmos al programador.El término CSP (cryptographic service
provider), o simplemente proveedor, se refiere a un paquete (o conjunto de
45
MD5: acrónimo de Message-Digest Algorithm 5.
28
paquetes) que suministran una implementación concreta de un conjunto de
aspectos de criptografía del API de Seguridad del JDK46.
El Security Toolkit for the Java Platform provee los siguientes CSPs:
El CSP Entrust: Soporta, entre otras cosas, implementaciones
especializadas de algoritmos RSA47 y DSA48.
o El CSP IAIK: implementa generación de claves y otras utilidades
tales colmos los algoritmos simétricos de cifrado y funciones hash
más comúnmente utilizados.
o
Cada clase motor tiene una correspondiente clase abstracta SPI (Service Provider
Interface) que define los métodos que el proveedor del servicio criptográfico debe
implementar [43].
Haciendo uso de la interfaz proveedora de servicios SPI de la JCA, los proveedores de
servicio criptográficos, tal como los suministrados por el Toolkit, pueden implementar
las características criptografícas de la JCA para invocar sus propias funciones de hash,
algoritmos de cifrado y otras utilidades que una aplicación de seguridad puede
requerir.
JCE [41]
La JCA, que gobierna el diseño de los paquetes de seguridad del J2SDK, es extendida
por la JCE (Java Cryptography Extensión) para incluir APIs de ciframiento (simétrico y
asimétrico), algoritmos MAC (Message Authentication Codes) y generación e
intercambio de llaves.
El JCE esta basado en los mismos principios de diseño de la JCA y utiliza la misma
arquitectura de proveedores.
Solo proveedores confiables49, es decir aquellos firmados por una entidad de confianza,
pueden ser incorporados dentro del framework del JCE. El CSP del Toolkit se llama
Entrust, e incluye un certificado que lo autentica ante la JCE cuando se carga, haciendo
que sus algoritmos e implementaciones queden disponibles para usar en las
aplicaciones.
Clases Low-level
El API de bajo nivel del Toolkit comprende los paquetes IAIK 50 , java.security y
javax.crypto. Las clases en este API soportan estándares PKCS 51 y dan acceso
46
JDK: Java Development Kit.
RSA: Algoritmo de cifrado de clave pública desarrollado por Rivest, Shamir y Adelman.
48
DSA: Digital Signature Algorithm, Algoritmo de Firma digital.
49
Los CSPs confiables son aquellos firmados por autoridades de certificación en Sun Microsystems o en
IBM.
50
IAIK: Conjunto de herramientas criptográficas basadas en Java.
51
PKCS: Public-Key Cryptography Standards. Define estándares para operaciones criptográficas que hacen
uso de la criptografía de llave pública.
47
29
directamente a la JCE y sus algoritmos y al proveedor de servicios criptográficos de
IAIK.
Clases High-level
El API de alto nivel del Toolkit, ubicado en el paquete com.entrust.toolkit 52 , provee
clases que implementan las tareas criptográficas mas comúnmente usadas. Estas
clases son más convenientes y útiles que sus pares de bajo nivel en IAIK o JCA.
Para la implementación del modelo que se especifica en el capitulo 5 del presente
documento, se hizo uso de las funcionalidades de este API.
A continuación se describen brevemente las clases utilizadas:
- Clase User
La clase User es la clase primaria del high-level API. Representa una entidad o
usuario final de un PKI.
Instanciando un User se tiene acceso, a través de métodos, a los certificados
públicos de un usuario, a las llaves privadas de un usuario, a una copia segura del
certificado público de verificación de la Autoridad de Certificación (CA), y a métodos
que permiten manejar las credenciales de un usuario (Ver numeral 4.2.2.4 Manejo
de usuarios y credenciales).
Existe una instancia de User por entidad y cualquier número de usuarios finales o
entidades pueden ser logueados al mismo tiempo sin interferir unos con otros.
En la Tabla 4 se presentan los métodos de la clase User utilizados en este trabajo
de grado.
Método
User()
getCaCertificate()
Descripción
Crea un objeto User
Si el usuario está logueado, retorna el
certificado de la CA almacenado en las
credenciales.
Obtiene un objeto CredentialReader.
Retorna el CredentialReader
utilizado cuando se invoca el método
login.
Obtiene un objeto CredentialWriter.
Retorna el CredentialWriter
establecido por el método
setCredentialWriter.
Retorna el certificado que corresponde
con el DN53 del emisor y número de
serial especificado.
getCredentialReader()
getCredentialWriter()
getUserCertificate(Name issuer,
java.math.BigInteger serialNumber)
52
53
Para detalles del paquete com.entrust.toolkit y los demás paquetes del toolkit ir a la referencia [37].
DN: Distinguished Name.
30
getUserCertificates()
getUserDN()
getVerificationCertificate()
login(CredentialReader credentialReader
, SecureStringBuffer password)
logout()
setConnections(java.lang.String entrust
IniFile)
Retorna todos los certificados de un
usuario.
Retorna el DN de un usuario.
Retorna el certificado de verificación
de un usuario.
Loguea a un usuario.
Desloguea a un usuario.
Establece la conexión con el EASM
(Entrust Authority Security Manager) y
con el Directorio, utilizando la
configuración devuelta por el archivo
entrust.ini54
setCredentialWriter(CredentialWriter cr Establece el CredentialWriter que
edentialWriter)
será usado para escribir en la
credencial del usuario.
Tabla 4. Algunos métodos de la clase User.
A continuación se detallan ciertos conceptos y consideraciones implícitas en algunos de
los métodos de la clase User expuestos en la tabla XX.
 Credential Readers y Writers
El objeto CredentialReader es utilizado para leer las credenciales y el objeto
CredentialWriter se utiliza para escribir en las credenciales.
Para mas detalle de los objetos credential reader y credential writer ver numeral
4.2.2.4 Manejo de usuarios y credenciales.
 SetConnections
El
método
setConnections(java.lang.String entrustIniFile)
establece
las
conexiones con el PKI (EASM Entrust Authority Security Manager) y el Directorio,
utilizando los parámetros de localización obtenidos del archivo de inicialización de
Entrust, entrus.ini.
La conexión con el PKI (Security Manager), es requerida durante la creación,
recuperación y manejo de llaves (ver numeral 4.2.2.4 Manejo de usuarios y
credenciales). La conexión con el Directorio permite la validación de certificados
permitiendo recuperar certificados y la lista de revocación de certificados (CRL).
 Login in
El procedimiento para hacer Log in de un objeto User usualmente tiene los
siguientes pasos:
Entrus.ini: Entrust initialization file. Archivo de inicialización de Entrust que contiene parámetros de
configuración tales como ubicación de servidores.
54
31
1. Se crea la instancia del objeto usuario
User user = new User();
2. Se crea una conexión al Directorio para que puedan ser validados los
certificados. También se crea una conexión con el PKI Entrust para hacer
posible el manejo de llaves.
user.setConnections(entrus.ini);
3. Se crea un objeto CredentialReader apropiado para la aplicación.
CredentialReader credentialReader = ...
4. Se crea y establece un objeto CredentialWriter.
CredentialWriter credentialWriter = ...
user.setCredentialWriter(credentialWriter);
Cuando un usuario hace log in se comprueba si las credenciales requieren
actualización (si existen nuevas llaves o certificados para el usuario), o si
hay cambio de password. Si hay actualizaciones o modificaciones por hacer
en las credenciales, se hace uso del CredentialWriter para llevar a cabo la
escritura.
5. El objeto User hace log in. Para esto se necesita, leer la credencial del
usuario utilizando el objeto CredentialReader, y el password para acceder a
la credencial.
SecureStringBuffer securePassword =
newSecureStringBuffer(PASSWORD);
user.login(credentialReader, securePassword);
Para mas detalle del Log in del usuario ver numeral 4.2.2.4 Manejo de usuarios y
credenciales.
- Clase PKCS7EncodeStream
La clase PKCS7EncodeStream permite cifrar, firmar, o cifrar y firmar datos de
acuerdo al estandar PKCS #755.
En la Tabla 5 se presentan los métodos de la clase PKCS7EncodeStream utilizados
en este trabajo de grado.
Método
PKCS7EncodeStream(User user,
java.io.OutputStream out, int operation)
Descripción
Constructor.
Crea un Nuevo
objeto PKCS7EncodeStream para
cifrar y/o firmar datos.
PKCS #7 : Cryptographic Message Syntax Standard. Estándar que describe una sintaxis para expresar
mensajes que han sido criptográficamente asegurados. http://www.ietf.org/rfc/rfc2315.txt?number=2315.
55
32
write(byte[] b)
Firma y/o cifra, tantos bytes como
tenga el arreglo de bytes b, y
escribe el resultado en el output
stream que se haya especificado en
el constructor.
close()
Cierra el output stream utilizado y
libera los recursos del sistema
asociados con dicho stream.
setDigestAlgorithm(AlgorithmID digest)
Especifica el algoritmo de resumen
de mensaje a utilizar para firmar
datos.
Tabla 5. Algunos métodos de la clase PKCS7EncodeStream.
A continuación se detallan ciertos conceptos y consideraciones implícitas en algunos de
los métodos de la clase PKCS7EncodeStream expuestos en la Tabla 5.
 Constructor PKCS7EncodeStream
Este objeto permite cifrar y/o firmar datos y escribir el resultado de la operación
en el output stream especificado con ayuda del método write.
Un usuario debe estar logueado antes de que una aplicación haga uso de este
método.
Los parámetros necesarios para hacer uso de este constructor son:
-
-
user: el objeto User que firma los datos y/o a para quien se cifran los
datos.El constructor utiliza las llaves de firma y cifrado por defecto del
usuario.
out: el output stream al que serán escritos los datos codificados.
operation: La operación a ejecutar. Esta puede ser:
 SIGN_AND_ENCRYPT = 1
 ENCRYPT_ONLY = 2
 SIGN_ONLY = 3
 EXPORT_CERTIFICATES = 4
 CLEAR_SIGN = 5
Para operaciones de firma y cifrado los algoritmos de cifrado y resumen de
mensaje son por defecto CAST 56 y SHA1 57 . Se pueden especificar otros
algoritmos haciendo uso de los métodos setEncryptionAlgorithm() y
setDigestAlgorithm() de la clase PKCS7EncodeStream.
 Procedimiento de firma
El procedimiento para firmar un mensaje PKCS #7 con el Toolkit, usualmente
tiene los siguientes pasos:
CAST: Algoritmo de cifrado por bloques publicado en junio de 1998 y diseñado siguiendo la metodología
de diseño "CAST" inventada por Carlisle Adams y Stafford Tavares. http://www.ietf.org/rfc/rfc2612.txt
57
SHA1: Secure Hash Algorithm, Algoritmo de Hash Seguro. http://www.ietf.org/rfc/rfc3174.txt
56
33
1. Se hace log in del usuario.
2. Se crea un objeto PKCS7EncodeStream usando el constructor
PKCS7EncodeStream encoder =
new PKCS7EncodeStream(user,new FileOutputStream(<output file>),
PKCS7EncodeStream.<operation>);
En el caso de firma el argumento operación es SIGN_ONLY.
3. Se especifican los algoritmos de cifrado y resumen de mensaje que se quiere
utilizar (opcional).
encoder.setDigestAlgorithm(AlgorithmID.sha);
encoder.setEncryptionAlgorithm(AlgorithmID.aes256CBC);
4. Se especifica la localización de los datos a firmar y se escriben los datos
firmados en el ouput stream especificado en el constructor.
FileInputStream input_data =
new FileInputStream(<location de datos de entrada>);
byte[] b = new byte[128];
int i = input_data.read(b);
while (i >= 0)
{
encoder.write(b, 0, i);
i = input_data.read(b);
}
5. Cierra el output stream cuando la operación de escritura (write) es
finalizada.
encoder.close();
- Clase PKCS7DecodeStream
La clase PKCS7DecodeStream decodifica datos que han sido firmados y/o cifrados
de acuerdo al estándar PKCS #7.
El Toolkit permite verificar datos que han sido firmados con más de una llave.
En la Tabla 6 se presentan los métodos de la clase PKCS7DecodeStream utilizados
en este trabajo de grado.
Método
PKCS7DecodeStream(User user,
java.io.InputStream inputStream)
close()
getDigestAlgorithm(int index)
Descripción
Constructor.
Crea un Nuevo objeto PKCS7DecodeStream
para descifrar o verificar datos.
Cierra el input stream utilizado y libera los
recursos del sistema asociados con dicho
stream.
Retorna el algoritmo de resumen de mensaje
34
que fue utilizado en la firma de los datos. El
parámetro index especifica la firma para la
cual debe ser retornado el algoritmo de
mensaje utilizado. La primera firma que
aparece en un mensaje tiene index 0.
getEncryptionAlgorithm()
Retorna el algoritmo que fue utilizado para
cifrar los datos.
getOperation()
Retorna la operación de seguridad que fue
ejecutada sobre los datos leídos del stream
(Por ejemplo ENCRYPT_ONLY ,SIGN_ONLY).
getSignerInfo(int index)
Retorna la información del firmate que realizó
la firma indicada por el index.
read(byte[] b, int off, int len)
Lee en el arreglo de bytes tantos bytes como
se indique en el parámetro len.
Tabla 6. Algunos métodos de la clase PKCS7DecodeStream.
A continuación se detallan ciertos conceptos y consideraciones implícitas en algunos de
los métodos de la clase PKCS7DecodeStream expuestos en la tabla 6.
 Constructor PKCS7DecodeStream
Este objeto permite descifrar y verificar datos. Un usuario debe estar logueado
antes de que una aplicación haga uso de este contructor.
Los parámetros necesarios para hacer uso de este método son:
-
user: el User que trata de descifrar los datos o verificar las firmas y
certificados.
inputStream: el input stream del cual se leen los datos PKCS7
codificados.
 Método read
Este método se bloquea hasta que algún dato esté disponible para su lectura.
Cuando se alcanza el final de un mensaje firmado, todas las firmas, y los
certificados públicos de los firmantes, son validados por lo cual se requiere que
se contacte al Directorio.
Para asegurar que efectivamente se verifican las firmas se puede llamar
explícitamente al método close.
 Procedimiento de verificación
El procedimiento para verificar un mensaje PKCS #7 firmado con el Toolkit,
usualmente tiene los siguientes pasos:
1. Se hace log in del usuario.
2. Se crea un objeto PKCS7DecodeStream usando el constructor
35
PKCS7DecodeStream decoder = new PKCS7DecodeStream(user,
new FileInputStream(<input file>));
El input file por lo general es un archivo PKCS #7 con extensión .p7m.
3. Se leen los datos firmados
byte[] b = new byte[128];
int i = decoder.read(b);
while (i >= 0)
{
i = decoder.read(b);
}
4.
Se cierra el input stream que lee los datos firmados.
decoder.close();
En resumen, las aplicaciones que se construyen con el Toolkit pueden ejecutar, entre
otras, las siguientes tareas de alto nivel:
- Manejar las credenciales de los usuarios (ver numeral 4.2.2.4 Manejo de usuarios y
credenciales). El manejo de credenciales incluye, entre otras cosas, su creación y
recuperación, key rollover58, cambios en el DN, actualización de las llaves de la CA y
validación de certificados.
- La creación y procesamiento de mensajes PKCS #7 (mensajes y datos que han sido
criptográficamente
asegurados,
digitalmente
firmados
o
digitalmente
empaquetados).
4.2.2.2. Interoperabilidad
El
Security Toolkit for the Java platform, es capaz de integrar aplicaciones
criptográficas con cualquier PKI que de soporte a los siguientes estándares abiertos:
-
Internet X.509 Public Key Infrastructure Certificate Management Protocols (PKIXCMP). PKIX-CMP está completamente explicado en el RFC 2510.
Public Key Cryptography Message Standard (PKCS #7).
Certification Request Standard (PKCS #10).
Personal Information Exchange Syntax Standard (PKCS #12).
X.509 v3 certificates.
Igualmente, el Toolkit implementa los siguientes estándares y protocolos:
-
PKCS #5—Password-based Cryptography Standard
(http://www.rsasecurity.com/rsalabs/pkcs/pkcs-5/index.html)
Key rollover: Generar automáticamente un par de llaves cuando el tiempo de vida de un certificado este
por acabar.
58
36
-
-
-
PKCS #7—Cryptographic Message Syntax Standard
(http://www.ietf.org/rfc/rfc2315.txt?number=2315)
PKCS #10—Certification Request Syntax Standard
(http://www.rsasecurity.com/rsalabs/pkcs/pkcs-10/index.html)
PKCS #11—Cryptographic Token Interface Standard
(http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html)
PKCS #12—Personal Information Exchange Syntax
Standard(http://www.rsasecurity.com/rsalabs/pkcs/pkcs-12/index.html)
Protocolo Secure Sockets Layer (SSL) , version 3.0
(http://home.netscape.com/eng/ssl3/ssl-toc.html)
ProtocoloTransport Layer Security (TLS), version 1.0
(http://www.ietf.org/rfc/rfc2246.txt). La versión 1.0 de TLS es una versión
actualizada de SSL versión 3.0
Internet X.509 Public Key Infrastructure Certificate and CRL Profile
(RFC 2459—http://www.ietf.org/rfc/rfc2459.txt?number=2459)
S/MIME version 2 Message Specification (RFC 2311) y S/MIME version 2 Certificate
Handling (RFC 2312—http://www.ietf.org/rfc/rfc2312.txt)
S/MIME version 3 Message Specification
(RFC 2633—http://www.ietf.org/rfc/rfc2633.txt) y S/MIME version 3 Certificate
Handling (RFC 2632—http://www.ietf.org/rfc/rfc2632.txt)
El Cryptographic Message Syntax (CMS)
(RFC 2630—http://www.ietf.org/rfc/rfc2630.txt)
Procesamiento y sintaxis de cifrado XML, Recomendación candidata W3C 02 Agosto
2002 (http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/)
Procesamiento y sintaxis de firma XML, Recomendación candidata W3C 12 Agosto
2002. (http://www.w3.org/TR/xmldsig-core/)
Decryption Transform for XML Signature, Recomendación candidata W3C 02
August 2002 (http://www.w3.org/TR/2002/CR-xmlenc-decrypt-20020802)
4.2.2.3. Modularidad
Para proveer una distribución modular de las capacidades del Toolkit, sus clases están
empaquetadas dentro de archivos jar (Java archive). Tal arreglo permite trabajar solo
con los archivos jar necesarios, que contienen las clases que se quieren utilizar en la
aplicación a construir.
Adicionalmente, todas las capacidades o funcionalidades del Toolkit están
empaquetadas en un único archivo jar llamado enttoolkit.jar. Este archivo contiene
todas las clases del Toolkit, por lo tanto, si se incluye en una aplicación, se podrá
hacer uso de todas las características del Toolkit.
4.2.2.4. Manejo de usuarios y credenciales
Conceptos
- Credenciales en sistemas PKI genéricos
En el contexto de una Infraestructura de Llaves Públicas (PKI), un usuario define una
entidad que ha sido identificada y aprobada por una Autoridad Certificadora (CA) y el
37
término credencial se refiere al conjunto de datos que definen dicha entidad y que
contiene información crítica o material clave del usuario. En Entrust PKI, un Entrust
digital ID, también conocido como profile, es el conjunto de datos criptográficos que
definen una entidad. Consiste en una porción pública (certificado público del usuario) y
una porción privada (llaves privadas del usuario).
La CA firma digitalmente la porción pública de la credencial de un usuario y la publica
como un certificado en el Directorio. Desde allí los certificados pueden ser accedidos
por otros usuarios que se encuentren dentro del dominio de la CA.
El certificado digital de un usuario normalmente incluye:




DN (distinguished name) del usuario.
Llave pública de verificación del usuario.
Llave pública de cifrado del usuario.
Firma digital y certificado público de verificación de la CA.
Un usuario mantiene secreta la porción privada de sus credenciales que consiste en la
llave privada de descifrado y la llave privada de firma.
En Entrust PKI, estas credenciales privadas se guardan en un Entrust profile que se
almacena como un archivo con extensión .epf. Un Entrust profile incluye:







DN (distinguished name) del usuario.
Llave privada de descifrado del usuario.
Llave privada de firma del usuario.
Historia de descifrado con la llave privada.
Certificado público de verificación y cifrado.
Certificado público de verificación de la CA.
Opciones propias de Entrust PKI.
En un PKI genérico se manejan conceptos similares a los expuestos. Los certificados
digitales publicados en el directorio del PKI, son firmados por la CA y representan las
credenciales públicas de un usuario. Los datos criptográficos privados del usuario (llave
privada de descifrado y llave privada de firma) son almacenados utilizando
convenciones similares a aquellas utilizadas en un Entrust profile, por ejemplo, los
datos se podrían almacenar en el formato portable de almacenamiento PKCS #12
(archivos *.p12 y *.pfx). Igualmente, el término credencial es utilizado para describir
un conjunto de datos que definen una entidad y que contienen la información
criptográfica crítica de un usuario.
El toolkit utiliza las credenciales o profiles, como la fuente de información criptográfica
de una entidad particular, y maneja por aparte los usuarios (clase User) y las
credenciales (paquete Credentials). Una aplicación o applet a construir debe estar en
capacidad de manejar tanto usuarios como credenciales.
- Modelo 2 -key-pair
38
Como es sabido, para que una entidad 59 pueda cifrar información o hacer uso de la
firma digital, debe contar con dos llaves: una pública a disposición de cualquier otra
entidad, y una privada que debe ser conservada únicamente por la entidad que va a
hacer uso de ella.
El manejo de la llave privada es responsabilidad de la entidad que la posea, y debe ser
de uso exclusivo de esta con el fin dar soporte a la integridad, autenticidad y no
repudio ofrecidos por la firma digital, y a la confidencialidad ofrecida por el cifrado.
¿Que pasa si esta llave privada se pierde? Lo primero que se supone es que debe
existir un repositorio con copia de las llaves privadas, pero, si esto es así, se estaría
atentando contra el no repudio ya que cualquier otra entidad en posesión de estas
llaves podría suplantar a otra. Por otro lado, en cuanto al cifrado, si una entidad no
tiene copia de su llave privada, se atenta contra la disponibilidad de la información ya
que cualquier información que haya sido cifrada con su llave pública no podrá ser
descifrada.
Para resolver el problema, el modelo 2-key-pair propone que en lugar de que el
usuario tenga un solo par de llaves, una pública y una privada, ahora tenga dos pares
de llaves cada una de uso específico: un par de llaves de cifrado y un par de llaves de
verificación.
El par de llaves de verificación da sustento a la firma digital. La llave privada de firma
es conocida únicamente por el usuario y no existe copia de esta, y la llave pública de
verificación se encuentra en un certificado digital disponible para otros usuarios.
El par de llaves de cifrado da sustento al cifrado de información. La llave privada de
descifrado es conocida únicamente por el usuario y, a diferencia de la llave privada de
firma, existe una copia de esta almacenada en una base de datos de llaves de cifrado.
Esta base de datos está cifrada y solo puede ser accedida por la CA Banrep. La llave
pública de cifrado se encuentra en un certificado digital disponible para otros usuarios.
- Credential readers y writers
El Toolkit utiliza los conceptos de credential readers y credential writers para denotar
los objetos que permiten crear, leer de y escribir a las credenciales.
El Toolkit cuenta con varias clases que extienden de estos objetos. En la Tabla 7 se
describen las más importantes algunas de las cuales fueron utilizadas en este trabajo
de grado.
Credential Readers
FilenameProfileReader – Lee un Entrust
profile de un archivo .epf.
TokenReader - Lee credenciales de un
hardware (token, smart card).
PKCS12Reader – Lee credenciales con
59
Credential Writers
FilenameProfileWriter - Escribe un Entrust
profile a un archivo .epf.
TokenWriter- Escribe credenciales a un
hardware.
PKCS12Writer- escribe credenciales
Entidad puede ser una persona o una aplicación.
39
formato PKCS #12.
conforme a PKCS #12 a un output stream
RoamingCredentialReader – Lee
RoamingCredentialWriter – escribe
credenciales de un servidor Roaming
credenciales a un Entrust Authority
(Entrust Authority Roaming Server)
Roaming Server.
CredentialCreator – crea credenciales
CredentialRecoverer – Recupera
credenciales
TokenCredentialCreator – crea
credenciales en un token.
TokenCredentialRecoverer - Recupera
credenciales de un token.
Tabla 7. Credential readers y credential writers.
- Roaming credentials
El servidor Roaming Entrust Authority Roaming Server permite que las credenciales de
un usuario sean almacenadas en un Directorio centralizado donde pueden ser
accedidas remotamente.
El Security Toolkit for the Java platform, permite escribir aplicaciones que hagan uso
del Entrust Authority Roaming Server ofreciendo funciones para crear, acceder, utilizar
y recuperar credenciales Roaming de los usuarios.
El soporte que ofrece el Toolkit al Roaming incluye entre otras cosas:
 Creación de credenciales Roaming: Toma el ID y password de un usuario y un
objeto CredentialCreator para enviar al Roaming Server una petición de
creación de credencial.
 Recuperación de credenciales Roaming: Toma el ID y password de un usuario y
un objeto CredentialRecoverer para enviar al Roaming Server una petición de
recuperación de credencial.
 Login Roaming: Toma el ID y password de un usuario para recuperar
credenciales del Roaming Server y realizar la operación de login.
 Cambio de id o password Roaming: envía una petición de cambio de id o
password al Roaming Server haciendo uso de un objeto
RoamingCredentialWriter.
El procedimiento para que un usuario haga log in al Roaming Server es similar al
expuesto en el numeral 4.2.2.1 (Arquitectura del Toolkit, Clases High-level, User, Log
in) con las siguientes modificaciones a los pasos 3 y 4.
3. (Paso 3) Se instancia un objeto credential reader, en este caso un
RoamingCredentialReader, pasando como argumento el id Roaming del
usuario y la ubicación del archivo entrust.ini que contiene los parámetros de
conexión con el servidor Roaming.
40
RoamingCredentialReader credReader =
new RoamingCredentialReader(userId, "entrust.ini");
4. (Paso 4) Se instancia y establece un objeto credential writer, en este caso un
RoamingCredentialWriter pasando los mismos argumentos que en el paso
anterior.
CredentialWriter credWriter =
new RoamingCredentialWriter(userId, "entrust.ini");
user.setCredentialWriter(credWriter);
- Administración de llaves
La principal tarea de un sistema PKI es administrar las llaves y certificados de los
usuarios. En enstrus PKI la mayoría de estas funciones son realizadas por él y por el
Toolkit internamente y no requieren intervención del usuario.
El Toolkit y el PKI se ayudan del event manager para llevar a cabo la administración de
llaves y certificados de los usuarios.
El event manager es un componente que coordina la administración de llaves. Es
contactado cuando un usuario hace log in, y periódicamente, para permitir a los
clientes consultar el estado de los usuarios y sus certificados y realizar acciones
correspondientes a algún evento ocurrido. Cuanto el event manager es contactado el
usuario puede ser informado de los siguientes eventos:






Actualización de llaves.
Cambio de DN.
Cambio de tipo de certificado.
Cambio del estado rollover permitido.
Movimiento del usuario a otra CA.
Notificación al cliente: el cliente solicita ser notificado de ciertos eventos.
Cuando un evento es completado el cliente almacena, entre otras cosas, la siguiente
información en su certificado:
 Cualquier certificado o llave nueva.
 El identificador de tipo de certificado y definición de certificado del usuario.
 El actual DN y rol del usuario.
- Identificando a un usuario
Antes de que un usuario de una aplicación pueda cifrar, descifrar, firmar mensajes, o
comunicarse de manera segura sobre una red, debe identificarse. Un PKI, cualquiera
que sea, debe estar en la capacidad de reconocer a un usuario como un miembro
confiable de una organización. La credencial de un usuario contiene la información
necesaria para autenticar el usuario ante una PKI y permitirle realizar operaciones
criptográficas.
41
El proceso de log in incluye leer y verificar la credencial de un usuario para asegurarse
de que las llaves que contiene están intactas y son validas. Si alguna de las llaves del
usuario se venció o necesita ser actualizada, es durante el login que esta actualización
se realiza y de allí que se necesite un objeto CredentialWriter (ver Credential readers
y writers en esta sección).
El proceso para llevar a cabo el log in de un usuario se especificó en el numeral
4.2.2.1.
- Validación de certificados
Gran parte del trabajo envuelto con la validación de certificados en el Toolkit es
realizado automáticamente. Por ejemplo, durante la operación de cifrado PKCS #7, los
certificados de los receptores del mensaje son validados automáticamente cuando la
aplicación llama el método setRecipients. En una operación de verificación de firma, los
certificados de los firmantes son validados automáticamente en el método read una
ves el mensaje se ha terminado de leer.
Todo esto es posible y tiene un buen funcionamiento partiendo del hecho de que la CA
en una PKI es la responsable de publicar y mantener actualizada la lista de revocación
de certificados (CRL).
Si se quiere validar explícitamente un certificado el Toolkit cuenta el método
user.validate(cert) donde user es un objeto tipo User (ver numeral 4.2.2.1, clase
user) y cert es un objeto tipo X509Certificate60.
60
X509Certificate es el tipo de objeto que representa un certificado digital conforme al estándar X.509.
42
5. MODELO PROPUESTO
El presente capítulo, describe el diseño e implementación del modelo propuesto para
poner a disposición los servicios del PKI utilizado en el Banco de la República, que
busca cumplir con el objetivo específico 2 mencionado en el numeral 1.3.2.
Primero se definen los conceptos de arquitectura y modelo, fundamentales para un
adecuado entendimiento de los diseños planteados en este trabajo de investigación.
Luego se aborda la arquitectura utilizada como base para el modelo propuesto.
Seguido de esto se detalla el diseño del modelo y se concluye con la explicación de
cómo este fue implementado.
5.1. CONCEPTOS DE ARQUITECTURA Y MODELO
Para un adecuado entendimiento de cómo se llegó a plantear el modelo, es necesario
aclarar lo que significa modelo y arquitectura para lo autores de este trabajo de grado.
Las definiciones que más se ajustan a arquitectura y modelo según la real academia
española son61:
Arquitectura: “Estructura lógica y física de los componentes de un computador”.
Modelo: “Arquetipo o punto de referencia para imitarlo o reproducirlo”.
Teniendo esto como base, para efectos de este trabajo de grado, se define
arquitectura como un conjunto de componentes y la relación entre ellos y modelo
como una implementación o aplicación de una arquitectura.
Estas definiciones implican que:



Una arquitectura es más general que un modelo.
Se pueden definir uno o más modelos basados en una misma arquitectura.
El modelo es una implementación real de lo que plantea una arquitectura.
En este documento se hace uso de las palabras arquitectura y modelo teniendo en
cuenta lo establecido en este numeral.
61
Definiciones de arquitectura y modelo tomadas de la real academia española. http://www.rae.es/
43
A continuación, en el numeral 5.2, se describe la arquitectura propuesta, base del
modelo implementado, describiendo sus componentes y la función que cumplen.
5.2. ARQUITECTURA PRELIMINAR
La arquitectura que se plantea está basada en los componentes de una arquitectura
orientada a servicios (ver Tabla 1) y tiene en cuenta el concepto de contenedores y
componentes que propone J2EE (ver Anexo 4) en donde un componente reside en un
contenedor.
La figura 7 muestra la arquitectura organizada en componentes que residen en
contenedores que están ubicados en maquinas diferentes. Unos componentes
conforman lo que sería el Service Requestor y otros lo que seria el Service Provider.
A continuación se describe cada componente de la arquitectura:
- Service
Requestor o consumidor de servicios: Representa la parte que requiere
hacer uso de los servicios web.
 Componentes del Service requestor
Estación de trabajo cliente: Contiene la aplicación cliente que va a hacer uso de
los servicios.
Application Server: Contiene un paquete de lógica en donde se encuentra un
componente denominado Invocador de Servicios encargado de recibir las
peticiones de un cliente e invocar al servicio solicitado.
Repositorio de descripción de servicios: Representa el directorio en donde están
publicados las descripciones de los servicios web. El Invocador de Servicios
accede a este directorio para obtener la descripción de un servicio y de esta
forma saber como invocarlo.
- Service
Provider o Proveedor de servicios: Representa la parte que pone los
servicios a disposición de los clientes.
 Componentes del Service Provider
Application Server - Web Container: El Application Server contiene al Web
Container en donde residen los Web Service Package. El Web Container provee el
ambiente de ejecución para Web Services.
Web Service Package: Consiste en un paquete contenedor de servicios. Este
paquete existe a manera de organización ya que servicios relacionados pueden
ubicarse en un mismo paquete. Los servicios de un paquete pueden comunicarse
entre sí y con servicios de otro paquete. Igualmente esto servicios podrían
comunicarse con una base de datos.
44
Para el caso de este trabajo de grado, los servicios web que pretendan poner a
deposición las funcionalidades del PKI, tendrán que comunicarse con un PKI.
Repositorio de descripción de servicios: Representa el directorio en donde los
servicios publican su descripción.
45
Service Provider
Service Requestor
Figura 7. Arquitectura propuesta.
46
5.3. DISEÑO DEL MODELO [13][23][44]
Esta sección presenta el modelo propuesto que está basado en la arquitectura
planteada en la Figura 7.
Como se mencionó en el marco teórico (ver numeral 3.2.4), existen muchas formas de
llevar cabo una arquitectura orientada a servicios y por lo tanto varias tecnologías.
Para el diseño del modelo que acá se describe, en donde se hace uso de Web Services
para la implementación de SOA, se optó por hacer uso de los APIs del JWSDP (Java
Web Services Developer Pack), específicamente de los APIs JAX-RPC (Java API for
XML-based)
y JAXR (Java API for XML Registries),
que hacen parte de la
especificación 1.4 de J2EE y permiten, junto con otra tecnologías, utilizar de forma
estandarizada las especificaciones de los Web Services dentro de una plataforma Java.
En los numerales que siguen se nombran las características que hacen de JWSDP el
método ideal para la implementación de los Web Services, y se exponen algunos de
sus APIs utilizados en este proyecto de grado.
Todos los conceptos expuestos en esta sección constituyen la base del modelo
orientado a servicios para poner a disposición los servicios ofrecidos por el PKI del
Banco de la República.
Cabe aclarar que este modelo no está ligado al PKI del Banco pues, según lo
establecido en el numeral 4.2.2.2, los desarrollos realizados aplican a cualquier PKI
que de soporte a ciertos estándares.
5.3.1.
Detalle del modelo
El modelo propuesto (ver Figura 8) está conformado por dos capas: la capa cliente y la
capa lógica de negocio.
- Capa
cliente: Constituida por la máquina cliente que representa al componente
Invocador de Servicios planteado en la arquitectura propuesta (ver Figura 7), quien
se encarga de obtener la descripción (WSDL) de los servicios Web y hacer todo el
proceso necesario para su posterior invocación.
- Capa
lógica de negocio: Conformada por uno o varios paquetes de servicios Web
que residen en un Web Container. En el modelo se representa un paquete de
Servicios Web de una aplicación cualquiera y el paquete de Servicios Web del PKI.
Los servicios del paquete PKI hacen uso de las librerías del Toolkit para comunicarse
con los componentes PKI, que para este caso son implementación propia de Entrust
PKI (Ver numeral 4.2).
A continuación, para un mayor entendimiento del diseño y funcionamiento del modelo,
se detallan los APIs utilizados.
5.3.1.1. Java WSDP [45]
El paquete Java WSDP (Java Web Services Developer Pack) es un toolkit integrado que
permite a los desarrolladores construir y probar aplicaciones XML, Web services y
aplicaciones Web, con la última tecnología e implementación de estándares de Web
Services.
Java WSDP en su versión 1.4 incluye, entre otras cosas, el paquete Java para XML
(Java XML Pack) conformado por los siguientes APIs:
- Java Architecture for XML Binding (JAXB) v1.0.3
- Java API for XML Processing (JAXP) v1.2.6
- Java API for XML Registries (JAXR) v1.0.6
- Java API for XML-based RPC (JAX-RPC) v1.1.2
- SOAP with Attachments API for Java (SAAJ) v1.2.1
El conjunto de API’s y herramientas Java que provee Java WSDP simplifican la
construcción y uso de Servicios Web, ya que permiten a los proveedores y
consumidores de estos servicios realizar tareas como registrar los servicios en un
repositorio estándar, describir las interfaces de los servicios, descubrir servicios Web
específicos, establecer comunicación entre Servicios Web existentes y aplicaciones,
entre otras.
¿Porque hacer uso de Java para implementar Web Services?
El contenido de los Servicios Web,
cualquier lenguaje de programación.
lenguaje de programación Java es
desarrollo de aplicaciones que hacen
que es lógica de negocio, puede ser escrito en
Sin embargo, por razones como la portabilidad, el
ideal para la construcción de Servicios Web y
uso de los mismos.
Como se mencionó en la teoría de Web services (Ver anexo 3), los servicios Web están
basados en XML que es un formato de datos neutral a la plataforma. Java es un
lenguaje de programación multiplataforma. Estas dos tecnologías proveen una solución
casi perfecta para el desarrollo de aplicaciones independientes y extensibles,
permitiendo interoperabilidad, portabilidad y flexibilidad.
A continuación se encuentra una breve descripción del Paquete Java XML y se detallan
los APIs de este paquete utilizados en este trabajo de grado.
Java XML Pack.
Conformado por un conjunto de APIs e implementaciones de alto nivel encargados de
abstraer la complejidad detrás del procesamiento de XML.
- API’s
Orientados a documentos: Son generalmente utilizados para interpretar
información almacenada en formatos XML.
48
 Java API for XML Processing (JAXP): Por medio de JAXP las aplicaciones pueden
analizar y transformar documentos XML sin necesidad
implementaciones particulares para el procesamiento de XML.
de
recurrir
a
 Java Architecture for XML Binding (JAXB): Provee APIs y herramientas que
automatizan el proceso de mapeo entre documentos XML y objetos Java.
- API’s Orientados a procedimientos: Facilitan el envió y la recepción de documentos
XML por medio de la red.
 Java API for XML Processing (JAXP)
 SOAP with Attachments API for Java (SAAJ): Permite a las aplicaciones crear
mensajes acorde a la especificación SOAP, con datos adjuntos
 Java API for XML Registries (JAXR): Provee un API para el acceso y la
modificación de las entradas en registros como UDDI.
 Java API for XML-based RPC (JAX-RPC): Empleado para crear productores y
consumidores de servicios Web que hacen uso de invocación de procedimientos
remotos basados en SOAP 1.1.
La comunicación entre los Web Services y las aplicaciones se puede efectuar de
diferentes formas, una de ellas es basada en invocación de procedimientos remotos
haciendo uso del API JAX-RPC. A continuación, en el numeral 5.3.1.2, se hace una
breve descripción de las características de este API que fue el seleccionado para
diseñar e implementar el modelo objeto de este numeral (Ver Figura 8).
5.3.1.2. Java API for XML-based RPC (JAX-RPC)
API Java utilizado para acceder a los Servicios Web a través de llamadas XML-RPC
basadas en SOAP. Permite a los clientes (consumidores) Java (ver Figura 8- Maquina
Cliente) llamar métodos de Servicios Web en ambientes distribuidos.
Aunque JAX-RPC es un API Java, no implica que los clientes y los Servicios Web deban
ser desplegados en plataformas Java. Con JAX-RPC un cliente Java puede hacer
llamadas y acceder métodos de Servicios Web en plataformas que no son Java, y de la
misma forma un cliente que no este en una plataforma Java puede acceder métodos
de Servicios Web en una plataforma Java (ver figura 9).
Figura 9: Interoperabilidad ofrecida por JAX-RPC.
49
Invocador De Servicios
Capa Cliente
Capa Lógica De Negocio
Figura 8. Modelo Propuesto.
50
A continuación se presentan conceptos importantes para poder entender y hacer uso
de JAX-RPC.
- Punto final de un servicio (Service Endpoint).
JAX-RPC confía en el WSDL para la descripción de un servicio. El WSDL describe a
los servicios Web como una colección de puertos también conocidos como puntos
finales o endpoints. Cada uno de estos endpoints identifica las diferentes acciones
provistas por el Servicio Web y los parámetros necesarios para poderlas ejecutar.
En JAX-RPC las solicitudes son direccionadas a su correspondiente endpoint.
Para hacer disponibles los Servicios Web a través de JAX-RPC es necesario proveer
una definición JAX-RPC del endpoint service. Esto involucra definir dos clases java:
 Una que defina la interfaz de los servicios JAX-RPC del punto final que describe
los métodos remotos que pueden ser invocados por el cliente, además de los
parámetros requeridos por cada uno (web Service N interface).
 Una que implemente la interfaz que provee el código necesario a ser ejecutado
por cada método (web Service N implementation).
Para los Servicios Web que no residen en plataformas Java se utilizan herramientas
de mapeo para generar, a partir de un documento WSDL, las definiciones JAX-RPC
de los puntos finales.
Después que el punto final de un servicio es definido se despliega en un contenedor
(Web Container) (ver figura 8).
- Artefactos (Artifacts)
Para poder manejar la comunicación entre los clientes y los puntos finales de los
servicios, JAX-RPC necesita varias clases, interfaces y otros archivos tanto en el
cliente como en el servidor. Estos archivos son llamados artefactos y son provistos
por una herramienta denominada wscompile la cual se trata mas adelante.
Entre los artefactos necesarios para la comunicación entre el cliente y el servidor se
encuentran los stubs, ties, serializadores (serializers), y des-serializadores
(deserializers).
 Los stubs son clases que representan el punto final de un servicio en el cliente,
lo que permite a un cliente JAX-RPC invocar un método remoto en el punto final
de un servicio, como si el método fuese local.
 El tie es el equivalente a un stub pero en el lado del servidor.
 Los serializadores y des-serializadores son clases utilizadas para convertir tipos
de datos Java en XML y tipos de dato XML en Java.
- Java-WSDL/XML mappings
Como se mencionó antes, JAX-RPC confía en el WSDL para la descripción de los
servicios Web, de hecho, poder acceder a la descripción WSDL de un servicio Web
es un requerimiento para la interoperabilidad de JAX-RPC.
Todas las implementaciones JAX-RPC deben ser capaces de producir documentos
WSDL a partir de la definición del punto final de los servicios, y viceversa. Esto es
posible haciendo uso de la herramienta wscompile.
- Binding
En todos los documentos WSDL se encuentra un elemento denominado binding
generado automáticamente por el wscompile. El binding entrelaza la definición
abstracta del punto final de un servicio, con los protocolos y elementos de
transporte a utilizar, por ejemplo SOAP 1.1 sobre HTTP.
- JAX-RPC runtime system [46]
Es el núcleo de la implementación JAX-RPC. Existe tanto en el lado del cliente como
en el lado del servidor y consiste en una librería que provee un conjunto de servicios
requeridos por los mecanismos de tiempo de ejecución de JAX-RPC.
En la figura 10 se puede observar lo que este componente hace internamente.
52
Figura 10. JAX-RPC runtime system
- Stubs, proxys dinámicos, e invocación dinámica
Los clientes JAX-RPC pueden invocar los servicios web de tres maneras:
 A través de un objeto local llamado Stub.
 A través de un proxy dinámico.
 Invocación dinámica de método a través de la interfase de invocación dinámica
de JAX-RPC DII (dynamic invocation interface).
Stubs
Invocar un método a través de un stub es invocar un método remoto haciendo que
parezca un llamado a un método local. El stub representa localmente al objeto
remoto. Los Stubs son utilizados cuando un cliente JAX-RPC sabe que método
invocar y como hacerlo (por ejemplo, que paramentos pasarle).
RESPUESTA
SOLICITUD
La figura 11 ilustra lo que debe hacer un cliente JAX-RPC para invocar un método
remoto a través de un Stub. Los pasos se describen en la tabla 8.
En el cliente:
En el servidor:
1. La aplicación cliente hace la
invocación RPC al objeto local
llamado Stub.
2. El Stub transforma la invocación
RPC en una solicitud para el
sistema de ejecución JAX-RPC del
lado del cliente.
3. El sistema de ejecución JAX-RPC
del lado del cliente mapea la
solicitud a un mensaje SOAP y lo
transmite como parte de una
solicitud Http.
En el cliente:
4. El sistema de ejecución JAX-RPC de
lado del servidor recibe el mensaje
SOAP de la solicitud Http, y lo mapea
a una invocación a un objeto local
llamado Tie.
5. El objeto denominado Tie invoca al
método solicitado del servicio Web.
6. El servicio Web procesa la solicitud.
10. El sistema de ejecución JAX-RPC
de lado del cliente extrae el
mensaje SOAP y lo mapea a una
respuesta para el Stub.
11. El Stub regresa la respuesta a la
aplicación cliente.
12. La aplicación cliente obtiene y
procesa la respuesta.
7. El servicio Web regresa la respuesta.
8. El objeto Tie convierte y envía la
respuesta al sistema de ejecución JAXRPC del lado del servidor.
9. El sistema de ejecución JAX-RPC del
lado del servidor mapea la respuesta a
un mensaje SOAP y lo transmite como
parte de una respuesta Http.
En el servidor:
Tabla 8. Pasos para invocar servicios Web haciendo uso de stubs.
53
Figura 11. Invocación de servicios Web haciendo uso de stubs.
Proxies Dinámicos
Un proxy dinámico es una clase que soporta dinámicamente puntos finales de servicio
en tiempo de ejecución, sin la necesidad de generar un Stub. Un cliente crea un Proxy
dinámico llamando al método getPort de la interfaz javax.xml.rpc.Service. Al efectuar
el llamado el cliente especifica el puerto y la interface del punto final de los servicios.
El método regresa una implementación construida dinámicamente del punto final de
los servicios, permitiendo que después el cliente pueda invocar el método sobre el
proxy dinámico.
Los pasos a seguir para invocar servicios web con este mecanismo son similares a los
expuestos en la tabla 8 y figura 11, solo que el stub es reemplazado por el proxy
dinámico.
Este mecanismo de llamado a servicios es el planteado en el modelo propuesto de este
trabajo de grado.
Interface Dinámica de Invocación (DII)
Algunas veces los clientes JAX-RPC necesitan invocar métodos remotos
dinámicamente, por ejemplo, considerando un escenario donde el cliente no conoce el
nombre del método remoto o su estructura antes de tiempo de ejecución. En estos
casos los clientes pueden utilizar interfaces dinámicas de invocación JAX-RPC (DII).
5.4. IMPLEMENTACIÓN DEL MODELO
Para abarcar la implementación del modelo se deben tener en cuenta los siguientes
aspectos:
54
- Se hizo uso de la herramienta de desarrollo JDeveloper de Oracle en su versión
10.1.3.1.0,
que ofrece soporte para la construcción de consumidores y
proveedores de servicios Web, según la especificación 1.4 de J2EE (JAX-RPC).
- El
servidor de aplicaciones que viene con JDeveloper es OC4J y es J2EE 1.4compliant.
- La base de datos se implementó en Oracle Database 10g Express Edition.
A continuación se detalla la implementación de cada componente especificado en el
modelo de la figura 8.
- Maquina cliente
 Aplicación cliente: componente de una aplicación que se encarga de hacer el
llamado a los servicios Web. Para que pueda hacer el llamado a los servicios
Web debe hacer uso del método
getPort(portName, serviceDefInterface);
donde porName es el puerto donde se encuentra el servicio y
serviceDefInterface es la interfaz Java del endpoint del servicio.
 Dynamic Proxy: Ver numeral 5.3.1.2, Stubs, proxys dinámicos, e invocación
dinámica.
 Client-Side JAX-RPC Runtime System: su implementación viene dada por el
OC4J instalado en la maquina del cliente y el API JAX-RPC62.
- Web Container
 Server - Side JAX-RPC Runtime System: su implementación viene dada por el
OC4J instalado en la máquina del servidor y el API JAX-RPC.
 Tie: Ver numeral 5.3.1.2, Artefactos
 Paquete de Web services de la aplicación: en este paquete se encuentran los
servicios del caso de aplicación que se detallan en el numeral 6.2.2
 Paquete de Web services PKI: En este paquete se encuentra el servicio PKI que
fue implementado en este trabajo de grado, conformado por 4 endpoints:
Autenticación Roaming, Firma, Verificación y Registro en el visor. El servicio de
registro en el visor (RegistrarVisor) busca cumplir con el objetivo específico 3
que se plantea en el numeral 1.3.2.
 Este paquete también contiene la interfaz Java (Web Service Interface) para el
servicio Web.
62
API JAX-RPC http://java.sun.com/webservices/jaxrpc/index.jsp
55
Un fragmento de código de la interfaz Java para el servicio PKI se presenta en
la figura 12.
Figura 12. Fragmento de código de la interfaz Java para el Web Service PKI.
Los fragmentos más importantes del WSDL del servicio PKI son:
- nombre del servicio
- operaciones o endpoints del servicio
56
- ubicación y nombre del puerto del servicio
Para observar en su totalidad el WSDL del servicio Web PKI referirse al código fuente.
 Librerías PKI: Se refiere al Toolkit, que para el caso de este trabajo de grado es
el Security Toolkit for the Java Platform especificado en el numeral 4.2.2.
- Componentes PKI:
Para la implementación del modelo se hizo uso del Roaming
Server, el Directory y el CA Key Management Server. Para mas detalle de estos
componentes ver numeral 4.2.2.4.
- UDDI:
Representa el repositorio de WSDLs donde los servicios publican su
descripción y los consumidores de servicio la buscan. Este componente no está
implementado en el modelo.
- Database Server: Representa la base de datos en donde el servicio RegistrarVisor
almacena los datos de la firma de un mensaje. Para mas detalle de la
implementación de esta base de datos ver numeral 6.4.2.
57
6. CASOS DE APLICACIÓN: TRANSFERENCIA DE FONDOS BANREP Y APLICATIVO DE
VERIFICACIÓN DE FIRMAS DIGITALES Y CONSULTA DE TRANSACCIONES (VISOR)
Para verificar el modelo planteado en el capítulo 5 se diseñó y desarrolló una aplicación
J2EE de transferencia de fondos que hace uso del modelo propuesto para acceder a las
funcionalidades del PKI. Esta aplicación permite comprobar las características
expuestas sobre Web Services y cumplir con el objetivo específico 5 descrito en el
numeral 1.3.2.
Para verificar la funcionalidad del servicio de registro de transacciones y dar
cumplimiento al objetivo específico 4 descrito en el numeral 1.3.2, se diseñó e
implementó un aplicativo, llamado visor, que permite consultar las operaciones de
firma que se realizan sobre las transacciones de la aplicación transferencia de fondos,
y verificar las firmas generadas.
A continuación, en el numeral 6.1, se realiza el análisis de las aplicaciones a
desarrollar, que en este caso son el aplicativo de transferencia de fondos
(Transferencia de Fondos BanRep) y el visor. Por otra parte, en el numeral 6.2, se
establece el diseño base de ambos aplicativos que fue abordado desde dos
perspectivas: Primero, planteando una arquitectura J2EE que representa una ubicación
distribuida de los componentes de la aplicación y la interacción entre ellos, y segundo,
planteando un modelo basado en esa arquitectura que representa la localización e
implementación real de los componentes.
En el numeral 6.3 se presentan y evalúan algunas herramientas tecnológicas que
facilitan el desarrollo de aplicaciones J2EE y de Web services, en el numeral 6.4 se
describe la implementación de los casos de aplicación haciendo uso de la herramienta
seleccionada, y por último en el numeral 6.5 se exponen los casos de prueba de las
aplicaciones.
6.1. ANÁLISIS
Este numeral describe por que se optó por la implementación de un aplicativo de
transferencia de fondos, la importancia y rol del mecanismo de auditabilidad y la
relación existente entre el aplicativo de transferencia de fondos y el visor. También se
definen los requerimientos funcionales y no funcionales de los casos de aplicación
Transferencia de Fondos Banrep y Visor, y se especifican los casos de uso utilizando
UML (Unified Modeling Language).
Visión general
La transferencia de fondos es el proceso de transferir dinero de una cuenta bancaria a
otra y normalmente se puede efectuar entre cuentas del mismo usuario o a cuentas de
otros usuarios. Para el caso de aplicación Transferencia de Fondos Banrep las cuentas
de un mismo usuario se denominan propias y las cuentas de otros usuarios que están
relacionadas a el se denominan asociadas.
58
Una aplicación para hacer transferencia de fondos cumple con los requisitos que se
buscan para poder hacer uso el modelo propuesto (ver figura 8) en su totalidad, pues
además de ser una operación muy común en una organización como el Banco, requiere
seguridad en los datos que maneja. Por simple que parezca, el transferir fondos entre
cuentas implica asegurar que esta operación sea efectuada por entes autorizados,
involucrando un proceso de autenticación que a su vez habilita el control de acceso a la
información. Igualmente en este tipo de operaciones se debe garantizar la integridad
de los datos, así como la autenticidad y el no repudio lo cual se puede lograr haciendo
uso de la firma digital. El PKI provee servicios que habilitan el uso de la firma (ver
numeral 3.1.2).
En este trabajo de grado el caso de aplicación que hace uso del modelo se llama
Transferencia de Fondos Banrep y los servicios que constituyen el paquete de servicios
Web de la aplicación son consignación, retiro y transferencia. Por otro lado se
encuentra el paquete de servicios PKI que contiene los servicios de autenticación, firma
digital, verificación de firma y registro en el visor. El modelo propuesto (ver figura 8)
hace una clara distinción entre los servicios Web del PKI y los servicios Web de una
aplicación teniendo en cuenta que estos se pueden comunicar entre si.
Cuando se realiza alguna operación en la aplicación, por ejemplo una consignación,
esta se debe firmar digitalmente y debe quedar un registro de dicha firma. Es en este
punto donde desempeña su función principal el mecanismo de auditabilidad, o Web
Service de registro, encargado de almacenar en una base de datos las operaciones
realizadas en la aplicación, firmadas digitalmente. Pero no solo basta con registrar las
operaciones efectuadas en la aplicación sino que se debe ofrecer una herramienta que
permita consultar las operaciones almacenadas y verificar la información allí
consignada, es decir, si el mecanismo de auditabilidad almacena la firma digital de una
operación, esta firma debe poder ser verificada posteriormente sin importar el tiempo
transcurrido desde la ejecución de la operación. La aplicación implementada para
cumplir con estos requerimientos se llama Visor.
6.1.1.
Requerimientos funcionales y no funcionales
A continuación se presentan los requerimientos funcionales y no funcionales del
aplicativo Transferencia de Fondos Banrep y del Visor.
Requerimientos funcionales Transferencia de Fondos Banrep
- Ingresar a la herramienta: La herramienta debe permitir a un usuario hacer el Log
in con un ID de usuario Roaming y un password. Cuando se ingresa a la
herramienta debe aparecer un campo para que el usuario digite su ID de usuario
Roaming y un campo para que el usuario digite su password. La herramienta
captura los datos, valida si es un usuario Roaming y, dependiendo del resultado de
esta validación, muestra al usuario la siguiente pantalla. En caso de que los datos
ingresados sean validos, el usuario entrará a la pantalla inicial de la herramienta
donde se le muestra una lista de diferentes aplicaciones a la cuales puede acceder,
entre ellas la Transferencia de Fondos Banrep. En caso de que los datos ingresados
no sean validos se muestra al usuario un mensaje de error y se solicita volver a
ingresar los datos.
59
- Ingresar
a la aplicación: Se debe comprobar que el usuario que ingresa a la
aplicación Transferencia de Fondos Banrep este autorizado para hacerlo. Para esto
la herramienta debe pedir el número de cédula del usuario y verificar que este
exista. Si la cédula existe se muestra al usuario la pantalla con el menú de la
aplicación. Si la cédula no existe se muestra al usuario un mensaje de error y se
solicita volver a ingresar la cédula.
- Transferencia de Fondos: La aplicación de transferencia
de fondos debe permitir al
usuario efectuar consignaciones, retiros, transferencias y consultas.
- Consignación: La aplicación debe permitir al usuario efectuar consignaciones a sus
cuentas o a cuentas asociadas las cuales deben de estar previamente inscritas en la
aplicación. Para efectos de concretar una consignación al usuario se le solicita el
número de cuenta a la cual desea efectuar la consignación, el tipo de cuenta (si es
propia o asociada), y el monto a consignar. La aplicación comprueba que la cuenta
existe y es o está asociada al usuario. Si la validación es correcta se realiza la
consignación y se muestra al usuario un mensaje de operación exitosa. Si la cuenta
no está registrada o no pertenece al usuario se despliega un mensaje de error y se
solicitan de nuevo los datos para la consignación.
- Retiro:
La aplicación debe permitir al usuario efectuar retiros solo de sus propias
cuentas. Para efectos de concretar un retiro al usuario se le solicita el número de
cuenta de la cual desea retirar y el monto a retirar. la aplicación valida que la
cuenta existe y pertenece al usuario y que el saldo de la cuenta sea suficiente para
poder retirar el monto deseado. Si la validación es correcta se realiza el retiro y se
muestra al usuario un mensaje de operación exitosa, de lo contrario se muestra un
mensaje de error al usuario y se solicitan de nuevo los datos para el retiro.
- Transferencia:
La aplicación debe permitir a un usuario efectuar transferencias de
fondos entre sus cuentas propias o hacia sus cuentas asociadas. Para ello se solicita
al usuario el número de cuenta de la cual desea transferir que debe ser propia, el
número de cuenta, propia o asociada, a la cual desea hacer la transferencia, y el
monto a transferir. La aplicación comprueba que las cuentas existan y pertenezcan
o estén asociadas al usuario, y que el saldo de la cuenta origen sea suficiente para
hacer la transferencia. Si la validación es correcta se realiza la transferencia y se
muestra al usuario un mensaje de operación exitosa, de lo contrario se muestra un
mensaje de error al usuario y se solicitan de nuevo los datos para la transferencia.
- Consultas:
La aplicación debe permitir a un usuario efectuar las siguientes
consultas:
 ver el saldo de una cuenta propia.
 ver los últimos 5 movimientos de una cuenta propia
 ver los movimientos de una cuenta propia en un período de tiempo determinado
por el usuario.
60
- Historial
de operaciones: La aplicación debe registrar en una base de datos los
movimientos de consignación, retiro y transferencia que realiza un usuario
almacenando la fecha y hora en que estas se realizaron.
- Firma digital: Las operaciones de retiro, consignación y transferencia de fondos del
aplicativo Transferencia de Fondos Banrep deben ser firmadas digitalmente y ser
registradas en una base de datos.
- Registro de transacciones: Todas las operaciones efectuadas en la aplicación deben
ser firmadas digitalmente y ser registradas en una base de datos. Por cada
operación se almacena la firma y el mensaje que es firmado junto con el
identificador de la aplicación, el identificador de la operación, la cédula del usuario,
y la fecha y hora de la operación.
Requerimientos funcionales Visor
- Ingresar a la herramienta: La herramienta debe permitir a un usuario hacer el Log
in con un ID de usuario Roaming y un password. Cuando se ingresa a la
herramienta debe aparecer un campo para que el usuario digite su ID de usuario
Roaming y un campo para que el usuario digite su password. La herramienta
captura los datos, valida si es un usuario Roaming y, dependiendo del resultado de
esta validación, muestra al usuario la siguiente pantalla. En caso de que los datos
ingresados sean validos, el usuario entrará a la pantalla inicial de la herramienta
donde muestra una lista de las operaciones registradas firmadas digitalmente, con
opciones para consultar y verificar una firma de una operación. En caso de que los
datos ingresados no sean validos se muestra al usuario un mensaje de error y se
solicita volver a ingresar los datos.
- Consultas:
La aplicación debe permitir al usuario consultar las operaciones
almacenadas en la base de datos del visor. Estas consultas reciben como
parámetro el identificador de la aplicación, el identificador de la operación o la
cedula del usuario. Las consultas deben poderse hacer por uno o mas parámetros
al tiempo.
- Verificación de firmas:
La aplicación debe permitir al usuario verificar una por una
las firmas digitales de las operaciones registradas en la base de datos del visor.
Requerimientos no funcionales de los casos de aplicación
- El sistema de Transferencia de Fondos Banrep y el visor deben ser aplicaciones que
estén disponibles 7x24 63 pues los usuarios deben poder acceder a ellas en el
momento que la soliciten.
- El tiempo de respuesta de una consulta no deberá ser mayor a 3 segundos.
63
Los sistemas 7X24 garantizan la disponibilidad para el usuario final los 7 días de la semana, las 24 horas.
61
6.1.2.
Casos de Uso
La figura 13 representa los casos de uso identificados para el aplicativo de
Transferencia de Fondos Banrep y el Visor.
La documentación de los casos de uso se encuentra en el anexo 5.
6.2. DISEÑO
Teniendo como base el hecho de que la plataforma J2EE es una infraestructura de
software que proporciona tecnologías para el diseño y desarrollo de aplicaciones de
negocio de múltiples capas, se plantea la arquitectura de aplicaciones basada en J2EE
presentada en el numeral 6.2.1. En el numeral 6.2.2 se describe el modelo del caso de
aplicación cuyo diseño se basa en la arquitectura del numeral 6.2.1.
Es importante entender que la arquitectura no indica como fueron implementados los
aplicativos Transferencia de Fondos Banrep y Visor, sino que constituye el fundamento
conceptual en el que se basa el modelo del caso de aplicación.
La arquitectura presentada constituye la representación distribuida de los componentes
que constituyen la aplicación que se quiere implementar, y es la base del modelo del
caso de aplicación, el cual representa el diseño sobre el cual se hizo la implementación
real de las aplicaciones.
6.2.1.
Arquitectura del caso de aplicación
La arquitectura del caso de aplicación (ver figura 14) se divide en cuatro capas:
Cliente, Web, Lógica de Negocio y Datos. A continuación se expone cada capa por
separado y se indica su relación con J2EE.
Capa cliente
Conformada por diferentes tipos de cliente. Los clientes están representados por medio
de nodos, donde cada nodo constituye una máquina. Para el caso de aplicación los
tipos de cliente pueden ser un browser o una aplicación de escritorio. Todo
componente u aplicación cliente está en capacidad de acceder otras capas.
Capa Web
Constituida por un servidor de aplicaciones J2EE (Application Server). Dentro del
Application Server reside un contenedor Web (Web Container) encargado de proveer
un ambiente de ejecución principalmente para los componentes de presentación (JSP y
Servlets).
62
Figura 13. Casos de uso Transferencia de Fondos Banrep y Visor.
63
Para enriquecer las aplicaciones cuya implementación se base en la Arquitectura
planteada, se hace uso patrones de software en el diseño. El Web Container tiene un
componente controlador, un dispatcher y un componente de presentación. La
interacción de estos tres componentes corresponde al patrón Front Controller donde:
- El
controlador es el punto inicial de contacto para manejar cualquier solicitud por
parte del cliente. Se encarga de delegar funciones a los otros componentes
dependiendo de lo que se solicite.
- El dispatcher es responsable por el manejo de las vistas y la navegación. Gestiona la
selección de la siguiente vista que será mostrada al usuario. Un dispatcher se puede
encapsular dentro de un controlador o se puede separar en otro componente que
trabaje de forma coordinada con el como se muestra en la Arquitectura de la figura
14.
- La presentación es un componente que contiene información a mostrar al cliente.
Consecuencias del uso del Front Controller [47]
- Centralizar el control: Un controlador maneja las peticiones.
- Mejora la manejabilidad de la seguridad: Un controlador
centraliza el control
proporcionando un punto de contención para intentos de accesos no autorizados a la
aplicación Web. Además, auditar una sola entrada a la aplicación requiere menos
recursos que distribuir los incidentes de seguridad entre todas las páginas.
- Mejora
la reutilización: Un controlador permite la reutilización de código ya que el
código común a todos los componentes reside en el controlador o es manejado por
este.
Capa lógica de negocio [48]
La capa de lógica de negocio de la arquitectura está compuesta por tres nodos:
- Un
Application Server que encapsula la lógica de negocio por medio de un EJB
Server
- Un repositorio o registro UDDI
- Un Application Server en el que
reside el Web Service Container o contenedor de
servicios Web.

Application Server - EJB Server
Está conformado por un componente BusinessDelegate, un SessionFachada, un
paquete de lógica de negocio, un DAO y un ServiceInvocator.
o
BusinessDelegate: utilizado para reducir el acoplamiento entre los clientes de
la capa de presentación y los servicios de negocio. . Las solicitudes de un
cliente de la capa de presentación son recibidas por el componente
BusinessDelegate
SessionFachada.
quien
a
su
vez
envía
la
solicitud
al
componente
Consecuencias del uso del BusinessDelegate
Reduce el acoplamiento, mejora la manejabilidad: Reduce el acoplamiento
entre las capas de presentación y de negocio ocultando a los clientes de la
capa de presentación todos los detalles de implementación de la capa de
negocio. Es fácil manejar los cambios porque están centralizados en un sólo
lugar.
o
SessionFachada:
El
SessionFachada
recibe
solicitudes
tanto
del
BusinessDelegate como de los clientes que no pertenecen a la capa de
presentación (por ejemplo un cliente de escritorio). De acuerdo a la solicitud,
el SessionFachada invoca a los objetos de negocio correspondientes
contenidos en el paquete de lógica de negocio.
Consecuencias del uso del SessionFachada

Expone una interfaz uniforme: Las interacciones entre los
componentes de negocio pueden ser muy complejas. Un patrón
SessionFachada abstrae esta complejidad y proporciona a sus clientes
un servicio de acceso uniforme a los objetos de negocio.

Reduce
el
acoplamiento,
incrementa la manejabilidad: Un
SessionFachada reduce el fuerte acoplamiento y la dependencia entre
los clientes y los objetos de negocio. El cliente ya no maneja las
interacciones complejas del flujo de trabajo ni se preocupa de las
interdependencias entre los objetos de negocio.

Centraliza el Control de seguridad: Las políticas de seguridad de la
aplicación se pueden controlar al nivel del Session Fachada. Debido al
acceso genérico del Session Fachada, es más fácil y más manejable
definir políticas de seguridad en este nivel que al nivel de los
componentes de negocio.
o
Lógica de negocio: Este paquete contiene los objetos de negocio que son
invocados por el SessionFachada. Los objetos de negocio, dentro de la lógica
que implementan, pueden requerir comunicarse con una base de datos, lo cual
sea hace a través del componente DAO, o requerir funcionalidad ofrecida por
uno o más servicios Web para lo cual existe comunicación con el
ServiceInvocator.
o
DAO [49]: Este componente implementa el patrón DAO (Data Access Object).
Dado que el acceso a datos varia dependiendo de la fuente de los datos, es
necesario tener un componente que abstraiga y encapsule estas diferencias de
acceso. DAO permite un acceso uniforme de los objetos de negocio a los
datos.
65
o
ServiceInvocator: Este componente es el encargado de encontrar y hacer el
llamado a los servicios Web dependiendo de la solicitud que haga un objeto de
negocio. Se encarga de la comunicación con el Registro UDDI para obtener la
descripción de un servicio, y basado en la descripción realizar el
correspondiente llamado al servicio.
Consecuencias del uso del ServiceInvocator


Abstrae la complejidad: El uso de un componente ServiceInvocator
encapsula la complejidad del proceso de búsqueda e invocación de
servicios Web. El cliente no necesita tratar con estos detalles porque
se ha delegado esta responsabilidad al ServiceInvocator.

Proporciona a los clientes un acceso uniforme a los servicios:
Proporciona un interfaz que asegura que todos los tipos de clientes de
la aplicación acceden de forma uniforme a los servicios.
Application Server – Web Service Server
El Web Service Server actúa como el ambiente de ejecución de los Web Services y
facilita el deployment y administración de los servicios.
Contiene uno o varios paquetes de servicios Web (Web Services Packages) que su
vez agrupan la implementación de un grupo de Web Services. Para efectos de este
trabajo de grado el Web Service Server debe permitir comunicación con una PKI.
Además los Web services pueden tener acceso a bases de datos y a repositorios de
descripciones de servicios Web como UDDI.

Registro UDDI
Representa el repositorio de descripciones de servicios Web (WSDL) en donde el
ServiceInvocator consulta los servicios. Igualmente, en este repositorio son
publicados los servicios contenidos en los Web Services Packages.

PKI
Representa la infraestructura de llaves públicas con la que deben interactuar los
servicios Web PKI. Es importante recordar que el objeto de este trabajo de grado es
abstraer la complejidad y funcionalidades de una PKI haciendo uso de servicios
Web.
Capa de Datos
La capa de datos provee los servicios de almacenamiento de datos en un repositorio
permanente (sistemas legados, bases de datos, directorios en línea, entre otros.
66
67
Capa Cliente
Capa Web
Capa Lógica de Negocio
Figura 14. Arquitectura del caso de aplicación64.
64
Se representan en color verde los componentes que constituyen el modelo orientado a servicios tratado en el numeral 5.1.1.
Capa Datos
6.2.2.
Modelo del caso de aplicación
En el numeral anterior (6.2.1) se planteó y describió una arquitectura de aplicaciones
que pretende ser la base para el diseño del modelo (ver figura 15) que se describe en
esta sección.
El modelo del caso de aplicación, objeto de esta sección, es el diseño en el cual se basa
la implementación de los casos de aplicación Transferencias de Fondos Banrep y Visor.
Representa la distribución real de los componentes y el tipo de tecnologías empleadas
para la comunicación entre ellos.
A continuación se trata en profundidad el modelo del caso de aplicación.
Consideraciones iniciales
Como ya se mencionó, el modelo aquí presentado representa la distribución real de los
componentes que constituyen el caso la aplicación, es decir, es en este diseño que se
basa la implementación de los casos de aplicación. También se mencionó que el diseño
del modelo esta basado en la arquitectura planteada en el numeral 6.2.1 (para aclarar
lo que para este trabajo de grado significa arquitectura y modelo ver numeral 5.1). Si
se compara la arquitectura de la figura 14 contra el modelo de la figura 15, se puede
observar una clara relación entre los componentes que conforman cada planteamiento,
con la diferencia principal en la forma como estos componentes están distribuidos.
El lector puede preguntarse el porque de la arquitectura y del modelo. Lo que se quiere
con la arquitectura es mostrar que todos los componentes que constituyen el caso de
aplicación pueden estar distribuidos en diferentes máquinas sin afectar la funcionalidad
que se pretende lograr. Esto da flexibilidad a un desarrollador a la hora de
implementar una aplicación con características similares a los casos de aplicación
propuestos en este trabajo de grado, pues le permite escoger la forma en que quiere
distribuir sus componentes. De otro lado se encuentra el modelo que, para el caso de
este trabajo de grado, constituye una forma de aplicar la arquitectura, es decir,
representa la distribución específica que los autores de este documento quisieron dar
a los componentes del caso de aplicación.
Teniendo en cuenta las consideraciones aquí expuestas, a continuación se detalla cada
parte de modelo del caso de aplicación.
Cliente Web
Representa la maquina del cliente. El tipo de cliente que se quiere representar es un
cliente Web cuyo papel juega un Browser. El Browser es el encargado de hacer
solicitudes a la aplicación las cuales llegan al componente Controlador, y recibir
respuestas en componentes Presentación que debe desplegar al usuario. El protocolo
utilizado para el envío de información desde el Cliente Web a la aplicación es HTTP o
SSL65.
Application Server
Contiene el Web container y el paquete Business Logic. Los componentes de la capa
Web y la capa lógica de negocio expuestos en el numeral 6.2.1, hacen parte de este
Application Server.
- Web container
 Controlador: Es el punto de convergencia de las solicitudes del cliente ya que se
encarga de recibir las solicitudes del Browser. Dependiendo de la solicitud
recibida decide sin enviar la solicitud al Dispatcher o invocar algún método de la
lógica de negocio expuesto a través del BusinessDelegate. (ver numeral 6.2.1,
capa Web).
 Distpatcher: Dependiendo de la solicitud recibida desde el Controlador decide
que componente Presentación enviar al cliente (ver numeral 6.2.1, capa Web).
 Presentación: Constituye la información devuelta por el Dispacher para ser
desplegada en el Browser de la máquina del cliente.
 Web Services aplicación: Para el caso de aplicación Transferencia de Fondos
Banrep este paquete contiene los servicios Web de consignación, retiro y
transferencia. Estos Web Services deben estar en capacidad de invocar a los
Web Services del paquete Web Services PKI y además deben poder acceder y
modificar la base de datos de la aplicación.
 Web Services PKI: Para el caso de aplicación Transferencia de Fondos Banrep
este paquete contiene los servicios de firma digital, verificación de firma,
autenticación Roaming y registro en el Visor. Estos servicios, a excepción del
servicio registro en el visor, deben poderse comunicar con el Roaming Server,
el Directory y CA key Management Server.
o
Firma digital: Este servicio Web debe ser invocado cada vez que se
realiza una operación de consignación, retiro o transferencia en la
aplicación Transferencia de Fondos Banrep y además debe llamar al
servicio Web de registro en el Visor.
o
Verificación de firma: Este servicio Web debe ser invocado por la
aplicación Visor, cuando un usuario elija la opción de verificar la firma
digital de una operación allí registrada.
o
Autenticación Roaming: Este servicio web es invocado cada vez que
un usuario intenta hacer Log-in para acceder a las aplicaciones de
Transferencia de Fondos Banrep y Visor.
SSL (Secure Socket Layer): protocolo que proporciona autenticación y privacidad de la información entre
extremos sobre Internet mediante el uso de criptografía.
65
70
o
Registro en el visor: Este servicio Web es invocado por el servicio de
Firma Digital y es el único que debe poder acceder y modificar la Base
de datos del Visor.
 Librerías PKI: APIs del Entrust PKI contenidas en un archivo .jar. (ver numeral
4.2.2.3)
- Business Logic
Este paquete contiene la lógica del negocio. Está constituido por los siguientes
componentes:
 BusinnessDelegate: Encargado de exponer una interfaz con los métodos de
negocio tanto de Transferencia de Fondos Banrep como del Visor según sea el
caso. Recibe solicitudes del Controlador y las envía al SessionFachada.
 Sessionfachada: Recibe las solicitudes del BusinnessDelegate y dependiendo de
la solicitud invoca a los objetos de negocio correspondientes que residen en el
componente Lógica Negocio.
 Lógica de negocio: Conformada por componentes llamados objetos de negocio.
Dependiendo de la solicitud recibida desde el SessionFachada, el objeto de
negocio invocado llama a un servicio Web o ejecuta su funcionalidad localmente.
 DAO: Este componente se encarga de centralizar todos los accesos a la base de
datos de la aplicación, es decir, solo a través de el se puede acceder a la base
de datos
 ServiceInvocator: Este componente recibe solicitudes de invocación de servicios
Web desde los objetos de negocio. Se encarga de buscar en el UDDI la
descripción del servicio Web solicitado (ya sea un servicio Web PKI o de
Aplicación), invocarlo y devolver la respuesta al objeto de negocio solicitante.
Este ServiceInvocator representa lo que en el modelo propuesto (figura 8), se
denomina invocador de servicios.
Para mas detalle de los componentes del Business Logia ver
lógica del negocio.
numeral 6.2.1, capa
UDDI
Almacena la descripción (WSDL) de los servicios Web contenidos en los paquetes Web
Services PKI y Web Services Aplicación.
Roaming Server
Contiene las credenciales del usuario Roaming necesarias para autenticarse ante las
aplicaciones Transferencia de Fondos Banrep y Visor, Para más detalle del Roaming
Server referirse al numeral 4.2.2.4.
71
Directory
Contiene la CRL publicada por la CA Banrep y los certificados públicos de los usuarios
de las aplicaciones Transferencia de Fondos Banrep y Visor. Tanto la CRL como los
certificados públicos son necesarios para que el Log-in del usuario sea válido (ver
numeral 4.2.2.4). Así mismo estos elementos son necesario al momento de verificar
una firma digital (ver proceso de firma en el numeral 4.2.2.1)
CA Key Management Server
Para mas detalle del CA Key Management Server o event manager ver numeral
4.2.2.4).
BD Aplicación
La aplicación Transferencia de Fondos Banrep hace uso de una base de datos que
representa el modelo de datos de la aplicación que permite realizar correctamente la
lógica de la aplicación. El modelo entidad relación de esta base de datos se presenta
en la figura 17.
BD Visor
En esta base de datos el servicio Web de Registro en el Visor almacena los datos
correspondientes a la firma digital de una operación realizada en una aplicación
cualquiera (por ejemplo Transferencia de Fondos Banrep).El modelo entidad relación
de esta Base de Datos se presenta en la figura 16.
6.3. HERRAMIENTA DE DESARROLLO
Los Web Services presentan una propuesta de integración de aplicaciones
programadas para diferentes plataformas y/o lenguajes. Esto, junto con las
arquitecturas orientadas a servicio, se está convirtiendo en la piedra angular de los
principios de diseño para la interoperabilidad de las nuevas aplicaciones de negocio.
Por ser una tecnología que todavía se encuentra en proceso de maduración y
robustecimiento, expertos desarrolladores crearon herramientas especializadas en
encapsular estas diferencias y facilitar la integración de plataformas.
Las arquitecturas orientadas a servicios son fundamentalmente construidas a través de
infraestructuras que permiten encapsular funcionalidades de negocio en componentes
reutilizables que son convertidos en públicos a través de interfaces bien definidas.
La herramienta de desarrollo que se presenta a continuación es utilizada para
implementar las aplicaciones de Transferencia de Fondos Banrep y el Visor.
- JDeveloper 10.1.3.1.0: Incluye el Oracle Application Server 10g (OC4J)
72
Aunque esta herramienta cubre grandes cantidades de tecnologías y estándares, lo
que a continuación se describe se centra específicamente en como soporta la
construcción
de
aplicaciones
con
Web
services.
73
Figura 15. Modelo del caso de aplicación66.
66
Se representan en color verde los componentes que constituyen el modelo orientado a servicios tratado en el numeral 5.3.
74
Figura 16. Modelo entidad–relación Base de Datos Visor.
Figura 17. Modelo entidad–relación base de datos Transferencia de Fondos
Banrep.
La base y principal componente de esta herramienta es el OC4J (Oracle Containers for
J2EE) 10g, diseñado para garantizar la interoperabilidad, manejabilidad, rendimiento,
escalabilidad y confiabilidad e integrar todos estos principios en una arquitectura
orientada a servicio.
OC4J es un contenedor que obedece completamente a la especificación J2EE 1.4, corre
en un archivo estándar basado en el JDK 1.4 Java Virtual Machine y provee completo
soporte para JSP’s, Servlets, EJB’s, Web Services y todos los servicios J2EE (ver anexo
4).
Características de OC4J
OC4J es ligero, requiere aproximadamente 35MB de espacio en disco y 20MB de
memoria, por lo cual el tiempo de instalación es muy corto (no más de 15 minutos). Es
fácil de usar y configurar y al estar escrito en lenguaje Java permite versiones de 32
75
bit y 64 bit en sistemas operativos estándar y plataformas de hardware como Solaris,
HP-UX, AIX, Windows NT/2000/2003/XP y Linux.
En la figura 18 se muestra la pila de protocolos y tecnologías que soporta el
contenedor OC4J. Obsérvese que este contenedor soporta la mayoría de tecnologías
que requiere la implementación de los casos de aplicación planteados en este trabajo
de grado.
JavaServer Pages (JSP) 2.0
Servlet 2.4
Enterprise Java Bean 2.0 -3.0
Session EJB
Entity EJB
Message Driven Beans
Java API for XML Registries (JAXR 1.0.5)
Java API for XML Processing (JAXP 1.1)
Java API for XML – Based RPC (JAX–RPC
1.1)
Java Database Connectivity (JDBC 3.0)
Java Naming and Directory Interface (JNDI
1.2)
Java Message Service (JMS 1.1)
Java Transaction API (JTA 1.0)
JMX Remote Access API
J2EE Application deployment 1.1
Java Management Extensions (JMX 1.2)
Figura 18. Pila de protocolos y estándares soportados por OC4J.
6.4. IMPLEMENTACIÓN
En este numeral se incluyen los aspectos más relevantes de la implementación de los
casos de aplicación Transferencia de Fondos Banrep y Visor.
Como se mencionó en el numeral 6.2.2, el diseño de las dos aplicaciones está basado
en un mismo modelo (figura 15) y por lo tanto los componentes que se implementan
76
en ambos casos son similares cambiando por supuesto la lógica que corresponde a
cada aplicación.
Para la implementación de las dos aplicaciones se hizo uso de las mismas herramientas
de desarrollo utilizadas en la implementación del modelo (ver numeral 5.4).
A continuación se presentan los fragmentos de código y consideraciones de
implementación más importantes para los dos casos de aplicación.
6.4.1.
Implementación Transferencia de Fondos Banrep
Lo importante a destacar en la implementación de este aplicativo es que sus
principales funcionalidades se ofrecen a través de servicios Web. Retiro y Consignación
son servicios Web que están el paquete Web Service Aplicación. La funcionalidad de
Transferencia hace uso de los servicios Web de Retiro y de Consignación.
En realidad, estos servicios son puertos que conforman el servicio Web WebServiceTF.
Un fragmento de código de la interfaz Java para el servicio WebServiceTF se presenta
en la figura 19.
Figura 19. Fragmento de código de la interfaz Java para el Web Service
WebServiceTF.
Los fragmentos más importantes del WSDL del servicio WebServiceTF son:
- nombre del servicio
- operaciones o endpoints del servicio
77
- ubicación y nombre del puerto del servicio
Para observar en su totalidad el WSDL del servicio Web WebServiceTF referirse al
código fuente.
6.4.2.
Implementación Visor
Esta aplicación no tiene servicios Web propios que implementen algún tipo de la
funcionalidad que ofrece, sino que hace uso de los servicios Web ya existentes. Para
poder ingresar a esta aplicación se hace uso del servicio Web autenticación Roaming y
para verificar firmas desde este aplicativo se invoca al servicio Web Verificar Firma.
Ambos servicios hacen parte del paquete Web Service Aplicación.
A continuación se presenta parte del código en donde esta aplicación hace el llamado a
los Servicios Web mencionados.
- Primero se obtiene el puerto del servicio Web (_port)
ServiceFactory factory = ServiceFactory.newInstance();
_port =
((tranferenciafondos.WebServicePKI_Service)factory.loadService(tranferenciafondos.WebS
ervicePKI_Service.class)).getWebServicePKISoapHttpPort();
...
- Para hacer el llamado al servicio Web Autenticación Roaming se invoca el servicio
esRoaming(roamingUserId, password) sobre el puerto obtenido.
public boolean esRoaming(String roamingUserId,
String password) throws java.rmi.RemoteException {
return _port.esRoaming(roamingUserId, password);
}
...
- Para
hacer el llamado al servicio Web Verificar Firma se invoca el servicio
VerificarFirma(roamingUserId, password, mensajeFirmado) sobre el
puerto obtenido.
public String[] VerificarFirma(String roamingUserId, String password, String mensajeFirmado)
throws java.rmi.RemoteException {
return _port.VerificarFirma(roamingUserId, password, mensajeFirmado);
}
...
Para más detalle referirse al código fuente.
78
6.5. CASOS DE PRUEBA
En este numeral se muestra el flujo de las pantallas de la aplicación Transferencia de
Fondos Banrep en las operaciones de consignación, retiro y transferencia. Para el caso
de aplicación Visor se muestra el caso de prueba verificar firma.
Lo primero que hacen los dos casos de aplicación es autenticar el usuario Roaming
para permitirle el acceso al aplicativo al que esté intentado ingresar. La pantalla de
Log-in se muestra en la figura 20.
Figura 20. Pantalla de Lon-in para la aplicación Transferencia de Fondos
Banrep y Visor.
6.5.1.
Transferencia de Fondos Banrep
Luego de hacer Log-in, si el usuario Roaming es valido se muestra la lista de
aplicaciones a las que tiene acceso. Esta pantalla se visualiza en la figura 21.
Figura 21. Pantalla de Lista de aplicaciones para la aplicación Transferencia
de Fondos Banrep.
Cuando el usuario elige ingresar a la aplicaron Transferencia de Fondos se solicita el
número la cédula. Esta pantalla se muestra en la figura 22.
79
Figura 22. Pantalla de solicitud de cedula del usuario en la aplicación
Transferencia de Fondos Banrep.
Si la cédula del usuario es válida se muestra el menú de la aplicación Transferencia de
Fondos Banrep. El menú se ve en la figura 23.
Figura 23. Pantalla de menú de la aplicación Transferencia de Fondos Banrep.
Consignar
La pantalla de consignación se muestra en la figura 24.
Figura 24. Pantalla de consignación en la aplicación Transferencia de Fondos
Banrep.
Retirar
La pantalla de retiro se muestra en la figura 25.
80
Figura 25. Pantalla de retiro en la aplicación Transferencia de Fondos Banrep.
Transferir
La pantalla de transferencia se muestra en la figura 26
Figura 26. Pantalla de transferencia en la aplicación Transferencia de Fondos
Banrep.
Si las operaciones son exitosas se muestra al usuario un mensaje de operación
exitosa. Ver figura 27.
Figura 27. Pantalla de respuesta cuando una operación es exitosa en la
aplicación Transferencia de Fondos Banrep.
Si las operaciones fueron exitosas se debió haber almacenado en la base de datos del
Visor la firma digital de estas operaciones.
Para el caso de las operaciones de consignación, retiro y transferencia anteriormente
realizadas, los registros almacenados en la base de datos del Visor se muestran en la
tabla 9.
81
Campo en
BDVisor
Id
Aplicación
Id
Operación
Cédula
Consignación
Retiro
Transferencia
Transferencia de Fondos
Transferencia de Fondos
Transferencia de Fondos
CON_6
RET_8
TF_6
63558948
63558948
63558948
Mensaje
Firmado
ID_OPERACION:CON_6,US
UARIO:63558948,FECHA_
HORA_OPERACION:200611-23
13:12:08.937,CUENTA_OR
IGEN:0,CUENTA_DESTINO:
2040,MONTO:10000,FECH
A_HORA_FIRMA:2006-1123 13:12:12.343
ID_OPERACION:RET_8,US
UARIO:63558948,FECHA_
HORA_OPERACION:200611-23
13:13:16.531,CUENTA_OR
IGEN:2040,CUENTA_DEST
INO:0,MONTO:10000,FEC
HA_HORA_FIRMA:200611-23 13:13:16.843
ID_OPERACION:TF_6,USUARIO:6
3558948,FECHA_HORA_OPERACI
ON:2006-11-23
13:13:54.203,CUENTA_ORIGEN:
2040,CUENTA_DESTINO:2043,M
ONTO:10000,FECHA_HORA_FIRM
A:2006-11-23 13:13:56.093
Firma
30820d1e06092a864886f7
0d010702a0820d0f30820d
0b020101310b300
…
30820d2006092a864886f70d010
702a0820d1130820d0d0201013
10b300906052b0e0
…
Timestamp
Firma
2006-11-23 13:12:12.343
30820d1e06092a864886f7
0d010702a0820d0f30820d
0b020101310b300906052
b0
…
2006-11-23 13:13:16.843
2006-11-23 13:13:56.093
Tabla 9. Registros almacenados en la base de datos del visor para operaciones
de consignación, retiro y transferencia.
6.5.2.
Visor
Luego de hacer Log-in, si el usuario Roaming es válido se muestra la lista operaciones
que se pueden verificar.
Para ejemplo, si se solicita verificar la firma de la operación CON_6 en la aplicación del
Visor el resultado de esta operación sería:
82
o
CASO A: Verificación de una firma válida
o
CASO B: Verificación de una firma invalida
83
7. RESULTADOS FINALES
Al comenzar este trabajo de grado se planteó un objetivo general y cinco objetivos
específicos, junto con unas preguntas de investigación. A continuación se describe
como estos fueron alcanzados y además se indica donde fueron respondidas las
preguntas de investigación que surgieron en el momento de analizar la problemática
(ver sección 2.1 Preguntas de investigación).
Objetivo General.
Diseñar e implementar un modelo orientado a servicios, haciendo uso de los protocolos
y estándares que enmarca la arquitectura SOA, para poner a disposición los servicios
de una infraestructura de llaves públicas (PKI).
El objetivo general planteado para este trabajo de grado se desglosa en cinco objetivos
específicos, como consecuencia, el cumplimiento de todos los objetivos específicos
dará como resultado el cumplimiento del objetivo general.
Objetivos específicos.
1. Investigar los protocolos y estándares ligados a los Web Services con el fin de
aplicarlos en el modelo propuesto.
Para un adecuado entendimiento y uso de los Web Services fue necesario identificar y
conocer los estándares que los soportan. Esto se logro mediante una investigación
detallada de los mismos (ver anexo 3), se recurrió a gran variedad de fuentes
bibliografías, se tuvo en cuenta la opinión de conocedores del tema y por ultimo toda
esta información fue recopilada y aplicada en el desarrollo del trabajo de grado.
2. Diseñar e implementar un modelo orientado a servicios haciendo uso de Web
Services, que permita poner a disposición al menos dos servicios ofrecidos por el
PKI Entrust utilizado en el Banco de la República.
Este objetivo fue alcanzado mediante el planteamiento e implementación del modelo
propuesto contemplado en el capitulo 5 del presente documento. Se inicio por aclarar
lo que para este trabajo de grado significan los conceptos de arquitectura y modelo,
para luego plantear una arquitectura preliminar que fuera la base del modelo
realmente implementado. La arquitectura representa de manera general los
componentes que constituyen el modelo
3. Desarrollar un mecanismo de auditabilidad que permita registrar en una base de
datos las transacciones realizadas a través del modelo propuesto, con el fin de
llevar control de las acciones entre aplicaciones y los servicios del sistema PKI.
Este objetivo fue logrado mediante el diseño e implementación de un Servicio Web de
registro denominado RegistrarVisor tratado en detalle en la sección 6.2.2.
4. Diseñar e implementar un aplicativo que permita verificar firmas digitales y
consultar las transacciones realizadas a través del modelo propuesto, con el fin de
verificar la funcionalidad del mecanismo de auditabilidad.
84
Este objetivo fue alcanzado mediante el diseño e implementación del aplicativo
llamado Visor tratado en la sección 6.4.2.
5. Desarrollar un aplicativo ejemplo que acceda a las funcionalidades del PKI a través
del modelo implementado.
Este objetivo fue logrado mediante el diseño e implementación del caso de aplicación
Transferencia de Fondos BanRep tratado en detalle en el numeral 6.4.1 de este
trabajo.
Preguntas de Investigación.
1. ¿Puede una estrategia SOA contribuir a una organización en el manejo de
evidencias digitales en el tiempo?
Si, el aplicativo visor es un claro ejemplo de ello, haciendo uso de un Servicio Web
especializado, en nuestro caso, el servicio RegistarVisor (ver seccion 6.2.2) es posible
almacenar las firmas digitales de las operaciones efectuadas para luego poder ser
utilizadas con fines de auditoria o evidencia digital.
2. ¿Es suficiente el modelo de firma digital ofrecido por las herramientas de PKI
existentes, para contribuir de manera significativa al manejo de la evidencia
digital?
No, la firma digital contribuye significativamente, pero son necesarias otro tipo de
operaciones, ejemplo de ello el aplicativo visor que hace uso de Servicios Web para
verificar la firma digital.
3. ¿Existen arquitecturas y/o modelos sencillos en su utilización en los que una
organización se pueda basar para implementar una estrategia de servicios PKI vía
SOA?
No, actualmente las organización deben realizar desarrollos particulares y por lo
general complejos para hacer uso de servicios PKI, desarrollos que no tienen nada que
ver con estrategias como SOA, esta fue una de las razones que dio como resultado
este trabajo de grado.
4. ¿Qué es y cuales son los componentes de una PKI?
Esta pregunta fue abordada y solucionada en la sección 3.1 PKI donde se describen los
conceptos generales, definición, y componentes de un PKI. El tema de una PKI se
abordo con más detalle en el anexo 1. Conceptos generales para entender que es una
PKI. Y como caso particular se hizo un análisis del PKI del Banco de la Republica
(sección 4.1).
5. ¿Qué es y por qué utilizar SOA?
Esta pregunta se respondió en la sección 3.2, donde se dieron las pautas y conceptos
necesario para entender que es, por que se utiliza y como se relaciona con las
85
aplicaciones empresariales, el tema de SOA fue abordado con mas detalle en el anexo
2. Características de SOA.
6. ¿Son los Web Services una forma valida de implementar una Arquitectura
Orientada a Servicios?
Si, claro ejemplo de ello es el modelo diseñado e implementado en este trabajo de
grado, fundamentado en la teoría que se puede apreciar en secciones como 3.3 Web
Services y en el anexo 3. Web Services.
7. ¿Qué ventajas ofrecen los Web Services ante otras tecnologías existentes
implementar una SOA?
para
La respuesta a esta pregunta se puede hallar en la sección 3.2.4 que aborda las
diferentes formas de lograr una arquitectura orientada a servicio, complemento de esta
respuesta es la sección 3.3.1, donde se responden aspecto como ¿Por qué utilizar Web
Services?.
8. ¿Qué ventaja tiene para una organización hacer uso de una PKI a través de SOA?
La respuesta a esta pregunta puede ser encontrada en la sección 1.2.
9. ¿Por qué en seguridad informática es necesario un mecanismo de auditabilidad?
Los mecanismos de auditabilidad permiten llevar controles rigurosos y de esta forma
evitar u identificar posibles fraudes o delitos, este tema fue abordado en la sección 2,
mostrando la importante de estos mecanismo en organizaciones como los Bancos.
10. ¿Qué ofrece la arquitectura J2EE para implementar una estrategia SOA?
Esta pregunta fue claramente respondida en la sección 3.4 J2EE y profundizada en el
anexo 4. Plataforma J2EE.
86
8. PROPUESTA PARA PROYECTOS FUTUROS
SOA es un estilo de arquitectura cuyo propósito primordial es lograr un débil
acoplamiento entre los componentes de software que interactúan entre si. Débil
acoplamiento (Loose Coupling) es una condición que pretende que los elementos no
estén atados uno al otro, tal que puedan ser intercambiados fácilmente. Bajo este
modelo se entiende cada servicio como un componente atómico que realiza una tarea
particular.
Para el caso de este trabajo de grado, los servicios se comunican directamente y no
hay un componente que los gestione o los “orqueste”. Esto implica que, por ejemplo,
una aplicación que quiera hacer uso de un servicio, debe hablarse directamente con el
servicio y, si este servicio hace uso de otros servicios, la comunicación con estos
también debe ser directa (uno a uno). El esquema orientado a servicios para este
trabajo de grado, suponiendo que se cuenta con 8 servicios y 4 aplicaciones, luce
entonces como se muestra en la Figura 28.
Figura 28. Comunicación directa entre servicios.
Existe en la industria un concepto que propone otra manera de implementar SOA, o
mejor, de organizar los servicios de una arquitectura de este tipo. Este concepto es
ESB (Enterprise Service Bus).
Este bus, al que se refieren algunas veces como “orquestador de servicios”, provee
integración y conectividad de servicios de una forma más organizada, pero no más
sencilla, que la comunicación directa entre servicios. Su uso permite a las aplicaciones
interoperar a través de un eje común evitando así el “desorden” que se puede generar
de una comunicación directa entre servicios. La imagen de la Figura 28 bajo el
concepto de ESB, luciría entonces como se muestra en la Figura 29.
Figura 29. Comunicación de servicios y aplicaciones a través de un bus.
87
Hacer uso de ESB sería una mejor e interesante manera de implementar SOA para el
caso de este trabajo de grado pero, por razones de tiempo, esto no hace parte del
alcance de este proyecto y por lo tanto se deja este tema como propuesta para
futuros desarrollos y/o investigaciones.
Otras razones por la cuales ESB no hizo parte de este trabajo de grado son:
- ESB todavía no es un estándar solidó.
- No hay claridad en lo que realmente es y se espera de ESB. Todos los miembros
de la industria se preocupan por defender su posición y concepto frente a esta
tecnología.
- La
mayoría de productos ESB son costosos y no parece ser algo fácil de
implementar por lo cual surge la pregunta ¿Cuál es la relación beneficio costo de
implementar ESB en una organización?
Estas y otras inquietudes que puedan surgir respecto al tema se dejan a consideración
de futuras investigaciones.
Por lo pronto se enuncian algunas características de ESB que pueden contextualizar al
lector interesado en explorar este tema.
Características del ESB [50]

Integra servicios de forma sencilla en la medida que representa distintas
tecnologías, sin modificar las aplicaciones subyacentes o presentar
dependencias de codificación que no admiten ninguna modificación. Los
modelos de interacción definidos incluyen invocación sincrónica y asincrónica,
publicación y suscripción, enrutamiento inteligente y orquestación con
seguimiento de estado.

Entrega datos de forma fiable a los destinos especificados de acuerdo a la
calidad de servicios configurada (por ejemplo, entrega una sola vez), y elimina
la necesidad de gestionar la retransmisión de datos si los servicios de recepción
no estás disponibles.

Proporciona conectividad final a los servicios web. Integración fiable, fácilmente
ampliable y segura de aplicaciones compatibles con servicios web.

Se puede decir que los 2 elementos que brindan el mayor valor agregado de
esta arquitectura son el débil acoplamiento entre los servicios (componentes),
que redunda en una mayor velocidad de respuesta (facilidad para planear y
ejecutar cambios,) y en el aumento en la reutilización de los recursos
tecnológicos, que implica una reducción en los costos y un mejor retorno de las
inversiones en tecnología que hace una organización.
La capacidad de respuesta de una organización a los cambios que puedan darse en el
mercado está fundamentada en los procesos del negocio. Es por esto que la industria
ha llegado a relacionar SOA con conceptos como Administración de Procesos del
Negocio (Business Process Management) y Desempeño del Negocio (Business
88
Performance Management). El valor que esto brinda a las organizaciones que adoptan
SOA y la implementan por medio de ESB, es la posibilidad de ver su organización como
un conjunto de procesos que involucran los diversos servicios, componentes, recursos
o personas a través de toda la empresa, y a partir de esto ser capaces de adaptarse a
cualquier necesidad y hacer frente al cambio de una manera mas optima y rápida.
89
LISTA DE FIGURAS
Figura 1. Componentes de una PKI. .................................................................... 15
Figura 2. Un sistema sencillo basado en servicios. ................................................ 16
Figura 3. Interacción entre los componentes generales de SOA. ............................. 17
Figura 4. API’s plataforma J2EE. ......................................................................... 22
Figura 5. Componentes PKI Banrep. .................................................................... 26
Figura 6. Arquitectura básica del “Security Toolkit for Java". .................................. 28
Figura 7. Arquitectura propuesta. ....................................................................... 46
Figura 9: Interoperabilidad ofrecida por JAX-RPC. ................................................. 49
Figura 8. Modelo Propuesto. ............................................................................... 50
Figura 10. JAX-RPC runtime system .................................................................... 53
Figura 11. Invocación de servicios Web haciendo uso de stubs. .............................. 54
Figura 12. Fragmento de código de la interfaz Java para el Web Service PKI. ........... 56
Figura 13. Casos de uso Transferencia de Fondos Banrep y Visor. ........................... 63
Figura 14. Arquitectura del caso de aplicación ...................................................... 68
Figura 15. Modelo del caso de aplicación .............................................................. 74
Figura 16. Modelo entidad–relación Base de Datos Visor. ....................................... 75
Figura 17. Modelo entidad–relación base de datos Transferencia de Fondos Banrep. . 75
Figura 18. Pila de protocolos y estándares soportados por OC4J. ............................ 76
Figura 19. Fragmento de código de la interfaz Java para el Web Service WebServiceTF.
...................................................................................................................... 77
Figura 20. Pantalla de Lon-in para la aplicación Transferencia de Fondos Banrep y
Visor. .............................................................................................................. 79
Figura 21. Pantalla de Lista de aplicaciones para la aplicación Transferencia de Fondos
Banrep. ........................................................................................................... 79
Figura 22. Pantalla de solicitud de cedula del usuario en la aplicación Transferencia de
Fondos Banrep. ................................................................................................ 80
Figura 23. Pantalla de menú de la aplicación Transferencia de Fondos Banrep. ......... 80
Figura 24. Pantalla de consignación en la aplicación Transferencia de Fondos Banrep. 80
Figura 25. Pantalla de retiro en la aplicación Transferencia de Fondos Banrep. ......... 81
Figura 26. Pantalla de transferencia en la aplicación Transferencia de Fondos Banrep.
...................................................................................................................... 81
Figura 27. Pantalla de respuesta cuando una operación es exitosa en la aplicación
Transferencia de Fondos Banrep. ........................................................................ 81
90
LISTA DE TABLAS
Tabla 1. Componentes generales de SOA. ............................................................ 17
Tabla 2. Componentes funcionales de SOA. .......................................................... 17
Tabla 3. Relación de componentes de SOA con tecnologías distribuidas. .................. 19
Tabla 4. Algunos métodos de la clase User. .......................................................... 31
Tabla 5. Algunos métodos de la clase PKCS7EncodeStream. ................................... 33
Tabla 6. Algunos métodos de la clase PKCS7DecodeStream. .................................. 35
Tabla 7. Credential readers y credential writers. ................................................... 40
Tabla 8. Pasos para invocar servicios Web haciendo uso de stubs. .......................... 53
Tabla 9. Registros almacenados en la base de datos del visor para operaciones de
consignación, retiro y transferencia. .................................................................... 82
91
CONCLUSIONES
1. Las tecnologías y herramientas para lograr una estrategia PKI vía SOA estaban ahí,
pero no existía como tal un diseño e implementación real que permitiera llevarlo a
la práctica.
2. Este trabajo de grado le sirve al banco, sus proveedores y contratistas, y en fin a
cualquier persona u organización que quiera construir aplicaciones seguras y
además tomar las ventajas de una arquitectura orientada a servicios.
3. Los Servicios Web se están convirtiendo en símbolo de interoperabilidad y bajo
costo, esto sumado a las características de SOA y la especificación J2EE, unifica lo
mejor de 3 tres tecnologías revolucionarias para el desarrollo de aplicaciones
empresariales óptimas.
4. La adopción e implementación de SOA por medio de Servicios Web otorga
innumerables ventajas competitivas a las organizaciones, entre ellas la rápida
adaptación al cambio y el alto nivel de respuesta a un mercado variable.
5. Los Servicios Web son una herramienta tecnológica que permiten acelerar el
crecimiento de los negocios electrónicos ya que permiten incorporar Web services
con diferentes funcionalidades, en diversos lenguajes de programación y sistemas
operativos. Los mensajes SOAP escritos en XML lograron unificar las tecnologías
existentes mediante Internet, el canal de comunicación masivo y de cobertura
mundial.
6. Los Servicios Web proporcionan mecanismos de comunicación estandarizados entre
diferentes aplicaciones, que interactúan entre sí para presentar información
dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre
estas aplicaciones, y que al mismo tiempo sea posible su combinación para realizar
operaciones complejas.
7. Llevar un control de acciones entre las aplicaciones y los servicios del sistema PKI a
través de un mecanismo de auditabilidad permite a las organizaciones mitigar los
incidentes informáticos y aplicar controles más eficientes.
8. El diseño orientado a servicios implementado por medio de Servicios Web que
permite poner a disposición servicios del PKI, permite usar las funcionalidades de
una PKI de forma sencilla.
9. El aplicativo de verificación de firmas nace de la necesidad actual de seguridad, y
permite verificar la legitimidad de una operación sin importar el tiempo
transcurrido.
10. El diseño e implementación de las arquitecturas y modelos propuestos basados en
estándares dan la ventaja de interoperabilidad e integración entre aplicaciones.
92
BIBLIOGRAFÍA
[1]. Gonzalo Álvarez Marañón, PKI o los cimientos de una criptografía de clave pública,
Artículo Publicado en Boletín del Criptonomicón
#57, Octubre de 1999,
http://www.instisec.com/publico/verarticulo.asp?id=32
[2]. Jordi Herrera Joancomartí, Criptografía de clave pública, Artículo Publicado en
Boletín del Criptonomicón #44, Marzo de 1999,
h ttp:// ww w.i ec . c si c. e s/C R IPT O N O M IC O N /ar ti cu l o s/ ex p er t os 4 4.h t ml
[3] W3C Consoritum. SOAP Version 1.2. Junio de 2003.
http://www.w3c.org/TR/2003/REC-soap12-part0-20030624/
[4]. Symeon Xenitellis, The Open–source PKI Book, 1999, 2000,
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm
[5] Juan Talavera, Infraestructura para la Criptografía de Clave Pública, Universidad
Nacional de Asunción, Enero 2005.
http://www.cnc.una.py/cms/cnc/content/pki.pdf
[6] W3C Consortium. Web Service Description Language (WSDL) Version 2.0. Agosto
2004. http://www.w3.org/TR/wsdl20/#intro
[7] Banco De la Republica, DECLARACIÓN DE PRÁCTICAS DE CERTIFICACIÓN CA
BANREP, Nov 1998.
[8] Sanjiva Weerawarana, Francisco Curbera Marzo 22. 2005. Web Services Platform
Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable
Messaging, and More. Prentice Hall PTR. Pag 1-25.
[9] José David Parra, Hacia una Arquitectura Empresarial basada en Servicios.
http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp
[10] Rigoberto Hernando Olarte, Pequeño Diccionario Informático.
http://www.monografias.com/trabajos22/diccionario-informatico/diccionarioinformatico.shtml
[11] Presentación “Fundamentos de Criptografía”, Maria Isabel Serrano, Agosto 2005.
[12] VeriSign, Introducción a la Criptografía de Clave Pública, 1999-2006 certiSur S.A.
http://www.certisur.com/docs/IntroCriptoPublica.html#4
[13] Sun Developer Network (SDN), Ed Ort, Hamesh Mandava, Bhakti Mehta , Java
Web Services Developer Pack - Part 2: RPC Calls, Messaging, and the JAX-RPC and
JAXM API
http://java.sun.com/developer/technicalArticles/WebServices/WSPack2/
93
[14] David Comín Roig, Wikipedia la enciclopedia libre.
http://es.wikipedia.org/wiki/X.509
[15] R. Housley, Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, Abril 2002
http://tools.ietf.org/html/rfc3280
[16] Universidad de Valencia.
http://www.uv.es/~sto/cursos/seguridad.java/html/sjava-18.html
[17] David Chappell, Tyler Jewell. Java Web Services. Marzo 2002. O'Reilly. Pag 19 –
21.
[18] Systinet the Web Services infrastructure company. Introduction to Web Services
Architecture. 2002. Pag. 8-22.
[19]
W3C
Consortium.
Web
http://www.w3.org/TR/ws-gloss/
Services
Glosary.
Abril
11
de
2004.
[20] Maria Gabriela Farias Terrens, Andrea Infante Salgado. Modelo de seguridad para
aplicaciones en canales públicos orientado a Web Services. Julio de 2005.
[21] Heather Kreger, IBM Software Group. Web Services Conceptual Architecture
(WSCA 1.0). Mayo 2001. IBM Software Group
[22] James McGovern, Sameer Tyagi, Michael Stevens and Sunil Matthew. Java Web
Services Architecture. 2003. Morgan Kaufmann Publishers.
[23] Ramesh Nagappan, Robert Skoczylas, Rima Patel Sriganesh. Developing Java Web
Services Architecting and Developing Secure Web Services Using Java. 2003 Wiley
Publishing Inc., Indianapolis, Indiana. Pag 23-617.
[24] W3C Consortium. Web
http://www.w3.org/TR/ws-arch/
Services
Architecture.
Abril
11
de
2004.
[25] Brett McLaughlin. Java & XML, 2nd Edition. O'Reilly.Second Edition September
2001.
[26] W3C Consortium. HTML
http://www.w3.org/TR/html4/
4.01
Specification.
24
de
Diciembre
de
1999.
[27] Doug Tidwell, James Snell, Pavel Kulchenko. Programming Web Services with
SOAP. O'Reilly. First Edition December 2001.
[28]. SafeGuard PKI, Infraestructura de clave publica - PKI
http://www.eurologic.es/soluciones/que-es-pki.htm
[29]. Definiciones de seguridad de la información y sus limitaciones., Diciembre 2004,
www.fistconference.org/data/presentaciones/queesseguridad.pdf
94
[30]. Alejandro Núñez Sandoval, Articulo Estándares de seguridad en la información,
Febrero de 2005.
http://www.enterate.unam.mx/Articulos/2005/febrero/seguridad.htm
[31]. Vicente Aceituno, CSIC, Definición de la Seguridad de la información y sus
limites. Diciembre 2004
http://www.microsoft.com/latam/technet/seguridad/glosario/default.mspx
[32] Tec de Monterrey, 2006
http://homepages.mty.itesm.mx/al450951/
[33]: Oracle Application Server 10g J2EE and Web Services An Oracle White Paper
August 2005 Pag. 4.
[34]: The J2EE™ 1.4 Tutorial For Sun Java System Application Server Platform Edition
8.2 Eric Armstrong.
[35]: J2EE Technology in Practice, by Rick Cattell and Jim Inscore (Addison-Wesley,
2001): http://java.sun.com/j2ee/inpractice/aboutthebook.html
[36] Security Toolkit for the Java® Platform, Programmer's Guide.
[37] Programmer's Reference, Detailed API reference information, Javadoc reference
material.
[38] Entrust, Entrust Authority Optional Components, Securing Digital identities &
Information. 2006.
http://www.entrust.com/pki/optional.htm
[39] Entrust, Securing Digital identities & Information – Public Key Infraestructure
(PKI) 2006.
http://www.entrust.com/pki/
[40] Sun Microsystems Inc.4150 Network Circle, JavaTM Cryptography Architecture
API Specification & Reference, Junio 25 - 2004
http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html
[41] Sun Microsystems Inc.4150 Network Circle, JavaTM Cryptography Extension (JCE)
Reference Guide for the JavaTM 2 Platform Standard Edition Development Kit (JDK)
5.0, Febrero 25 – 2004.
http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/JCERefGuide.html
[42] JCA Sun, Arquitectura Criptográfica de Java (JCA).
http://www.uv.es/~sto/cursos/seguridad.java/html/sjava-40.html
[43] Sun, Seguridad en la Plataforma Java 2 JDK 1.2, 1996 – 2006.
http://www.programacion.com/java/tutorial/security1dot2/1/
[44] Sun Microsystems Inc.4150 Network Circle, Java BluePrints: Patterns, Guidelines,
Conventions, and Code, Mayo 2004.
http://java.sun.com/blueprints/guidelines/designing_webservices/html/
95
[45] Sun Microsystems Inc.4150 Network Circle, Java Technology & Web Services
Downloads - Java Web Services Developer Pack.
http://java.sun.com/webservices/downloads/1.4/index.html
[46] Roberto Chinnici (Sun Microsystems, Inc.), Java™ API for XML-based RPC JAXRPC 1.1 -2005
[47] Sun Microsystems Inc.4150 Network Circle, Catálogo de Patrones de Diseño J2EE.
I.- Capa de Presentación, 1996-2006.
http://www.programacion.com/java/tutorial/patrones/4/
[48] Sun Microsystems Inc.4150 Network Circle, Catálogo de Patrones de Diseño J2EE.
Y II: Capas de Negocio y de Integración.
http://www.programacion.com/java/tutorial/patrones2/1/
[49] 2001-2002 Sun Microsystems, Inc., Core J2EE Pattern Catalog, Core J2EE
Patterns - Data Access Object.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
[50] Sonic ESB, Sonic Software, Roy Schulte, Gartner Inc noviembre de 2004
[51] Documento de políticas de seguridad del Banco de la República.
96
ANEXOS
ANEXO 1. Conceptos generales para entender que es una PKI
- Criptografía de llaves públicas
La criptografía de clave pública, también conocida como criptografía asimétrica, se
basa en la idea de un par de llaves matemáticas dependientes: una pública conocida
por todos que se publica junto con la identidad del propietario, y otra privada sólo
conocida por el usuario a quien le es asignada, la cual es imprescindible que se
mantenga en secreto [1] [2] [28].
Estas claves tienen la propiedad de que cada una de ellas invierte la acción de la
otra pero a partir de una no se puede obtener la otra [2].
La criptografía de llave pública tiene su principal aplicación en la en la protección de
datos e identificación de una entidad ante otra, y los mecanismos que soportan
estas aplicaciones son el ciframiento y la firma digital. El funcionamiento básico de
la criptografía asimétrica se muestra en la Figura I.
Figura I. Funcionamiento básico de la criptografía asimétrica.

Ciframiento
Es el proceso mediante el cual los datos originales de un mensaje se traducen a
un código secreto, con el propósito de aumentar la seguridad de estos y evitar
que sean vistos por personas no deseadas. Sólo las personas autorizadas
podrán, con una clave, descifrar el mensaje para recuperar los datos originales
[10].
La información cifrada con una clave sólo puede descifrarse con la otra del
mismo par, así, cuando se quiera enviar un mensaje seguro a un usuario, se le
enviará la información cifrada con su clave pública de tal forma que sólo ese
usuario destinatario que posea la clave privada correspondiente, podrá descifrar
la información.

Firma Digital
A través de la firma digital y su funcionamiento se puede dar soporte a los
siguientes principios de seguridad:
97
Autenticación: se define como la capacidad de verificar que una entidad
es quien o lo que dice ser [31].
Integridad: Garantizar que la información no será alterada, eliminada o
destruida por entidades no autorizadas [30].
No repudio: se define como la capacidad de afirmar la autoría de un
mensaje o información del que un tercero es autor. De este modo el
autor no puede negar su propia autoría. [29].
¿Como puede la firma soportar dichos principios de seguridad?
La firma digital tiene dos características principales. La primera es que sólo
puede ser generada por el poseedor de la clave privada y puede ser verificada
por cualquiera que conozca la clave pública del firmante. La segunda, es que es
dependiente del documento a firmar, es decir, la firma digital de un documento
no puede emplearse para firmar otro documento [28] (esto debido al
funcionamiento de la firma digital explicado mas adelante).
Lo anterior lleva a deducir que la firma puede soportar la autenticación y no
repudio, ya que, haciendo uso de la llave pública del emisor se puede saber que
fue él quien firmó y este, quien es el poseedor de la llave privada, no puede
negar su firma.
La integridad,
haciendo uso de la firma digital,
esta dada por su
funcionamiento (Figura II). Básicamente si A quiere enviar un mensaje a B
haciendo uso de la firma digital se siguen los siguientes pasos: [3]
1. A genera un resumen del mensaje utilizando una función unidireccional de
resumen (hash).
2. A cifra el resumen con su clave privada generando por tanto la firma digital.
3. A envía el mensaje junto con el resumen cifrado a B.
En la verificación de la firma (Figura III):
1. B genera un resumen del mensaje recibido de A usando la misma función de
hash. Después descifra con la clave pública de A el resumen firmado. Si el
resumen firmado coincide con el resumen que él ha generado, la firma es
válida y el mensaje no ha sido alterado (integridad).
98
Fuente:
Figura tomada de http://www.cnc.una.py/cms/cnc/content/pki.pdf
Figura II. Funcionamiento de la Firma Digital – Cuando A envía mensaje firmado a B
Fuente: Figura tomada de http://www.cnc.una.py/cms/cnc/content/pki.pdf
Figura III: Verificación de la Firma Digital – Cuando B recibe el mensaje y verifica su
origen
- Certificado Digital [12]
Dado que el ciframiento y la firma digital dependen de la llave pública, y esta se
encuentra disponible para ser consultada y utilizada por cualquier entidad que la
requiera, es necesario asegurar que esta llave es confiable.
99
¿De qué forma el receptor puede asegurar que la clave pública enviada por el emisor,
o aquélla que puede obtener de un repositorio o directorio público, es efectivamente de
quién dice ser?
La solución es el Certificado Digital. Un Certificado Digital es un archivo que contiene la
clave pública de un usuario firmada digitalmente por alguien confiable para hacerlo.
Adicionalmente también contiene información sobre la persona o entidad a quien se le
otorga el certificado, periodo de validez del certificado, e identidad de la entidad que
emite el certificado [28].
Cada vez que alguien envía un mensaje, le adjunta su Certificado Digital. El receptor
del mismo primero utiliza ese Certificado Digital para verificar que la clave pública del
autor del mensaje es auténtica y, posteriormente, emplea esa misma clave pública
para verificar o cifrar el mensaje en sí mismo.

Formato de los certificados digitales [14][15][16]
X.509 es un estándar del ITU-T67 y el ISO/IEC 68 que se publicó por primera
vez en 1988.
X.509 especifica, entre otras cosas, formatos estándar para certificados de
claves públicas y un algoritmo de validación de ruta de certificación.
El estándar internacionalmente aceptado para Certificados Digitales, es el
X.509 en su versión 3, publicado en 1996.
o
X.509 v3 [16]
Los elementos del formato de un certificado X.509 v3 son (Figura IV):

Versión. El campo de versión contiene el número de versión del
certificado. Los valores aceptables son 1, 2 y 3.

Número de serie del certificado. Este campo es un entero asignado por la
autoridad certificadora. Cada certificado emitido por una CA debe tener
un número de serie único.

Identificador del algoritmo de firmado. Este campo identifica el algoritmo
empleado para firmar el certificado (como por ejemplo el RSA o el DSA).

Nombre del emisor. Este campo identifica la CA que ha firmado y emitido
el certificado.

Periodo de validez. Este campo indica el periodo de tiempo durante el
cual el certificado es válido y la CA está obligada a mantener información
sobre el estado del mismo. El campo consiste en una fecha inicial, la
fecha en la que el certificado empieza a ser válido y la fecha después de
la cual el certificado deja de serlo.
67
ITU-T: International Telecommunication Union-Telecommunication Standarization Sector.
http://www.itu.int/ITU-T/
68
ISO/IEC: International Standards Organization / International Electrotechnical Commission.
http://www.standardsinfo.net/isoiec/index.html
100

Nombre del sujeto. Este campo identifica la identidad cuya clave pública
está certificada en el campo siguiente. El nombre debe ser único para
cada entidad certificada por una CA dada, aunque puede emitir más de
un certificado con el mismo nombre si es para la misma entidad.

Información de clave pública del sujeto. Este campo contiene la clave
pública, sus parámetros y el identificador del algoritmo con el que se
emplea la clave.

Identificador único del emisor. Este es un campo opcional que permite
reutilizar nombres de emisor.

Identificador único del sujeto. Este es un campo opcional que permite
reutilizar nombres de sujeto.

Extensiones. Campo opcional. Las extensiones del X.509 v3 proporcionan
una manera de asociar información adicional a sujetos, claves públicas,
etc. Un campo de extensión tiene tres partes:
1. Tipo de extensión. Es un identificador de objeto que proporciona
la semántica y el tipo de información (cadena de texto, fecha u
otra estructura de datos) para un valor de extensión.
2. Valor de la extensión. Este subcampo contiene el valor actual del
campo.
3. Indicador de importancia. Es un flag que indica a una aplicación si
es seguro ignorar el campo de extensión si no reconoce el tipo. El
indicador proporciona una manera de implementar aplicaciones
que trabajan de modo seguro con certificados y evolucionan
conforme se van añadiendo nuevas extensiones.
El ITU y el ISO/IEC han desarrollado y publicado un conjunto de
extensiones estándar en un apéndice al X.509 v3:
o
o
o
Limitaciones básicas. Este campo indica si el sujeto del
certificado es una CA y el máximo nivel de profundidad de un
camino de certificación a través de esa CA.
Política de certificación. Este campo contiene las condiciones bajo
las que la CA emitió el certificado y el propósito del certificado.
Uso de la clave. Este campo restringe el propósito de la clave
pública certificada, indicando, por ejemplo, que la clave sólo se
debe usar para firmar, para la encriptación de claves, para la
encriptación de datos, etc. Este campo suele marcarse como
importante, ya que la clave sólo está certificada para un
propósito y usarla para otro no estaría validado en el certificado.
101
Fuente:
Figura tomada de www.alu.ua.es/f/fgc10/CERTIFICADOS%20X.509.ppt
Figura IV. Campos de un certificado X.509 v3.
102
ANEXO 2. Características de SOA
SOA es una forma de arquitectura para sistemas distribuidos caracterizada por las
siguientes propiedades:
- Vista lógica:
el servicio es una abstracción (Vista Lógica) de los programas, bases
de datos, procesos de negocio, etc., definido en términos de lo que hace (llevando a
cabo una operación de negocio).
- Orientación
a Mensajes: el servicio se define formalmente en términos de los
mensajes intercambiados entre agentes proveedores y solicitantes, y no esta
basada en las propiedades de los agentes. La estructura interna del agente
(lenguaje de programación, BD, proceso, etc.) se abstrae en SOA. Esto permite
incorporar cualquier componente o aplicación a esta arquitectura “decorando” estos
componentes con software de gestión y conversión.
- Orientación a la descripción: un servicio se describe con meta datos procesables. La
descripción da soporte a la naturaleza pública de SOA: solo se incluyen en la
descripción aquellos detalles que se exponen públicamente y son importantes para
el uso del servicio.
- Granularidad: los servicios tienden a usar un pequeño número de operaciones con
mensajes relativamente complejos.
- Orientación a la red: los servicios tienden a usarse a través de la red.
- Neutral a la plataforma: los mensajes se envían en un formato estándar y neutral a
la plataforma, distribuido a través de XML.
- Localización
transparente: la transparencia en la localización es una característica
clave en la arquitectura orientada a servicios (SOA). Los consumidores de un
servicio no conocen la localización de un servicio si no hasta que la obtienen en el
registro. La localización e interacción dinámica con un servicio en tiempo de
ejecución permite a la implementación del servicio moverse de una localización a
otra sin que el cliente se entere, dándole mayor versatilidad y eficiencia, la
distribución de cargas en ejemplo de ello.
103
ANEXO 3. Web Services
1. ¿Qué son?
Un Web Service es un conjunto de funciones que se publica en la red, generalmente
Internet, para que sea localizado e invocado.
Desde el punto de vista del consumidor, un Web Service es una caja negra accedida
por HTTP, que utiliza mensajes XML sobre SOAP, recibe un mensaje de invocación del
servicio que presta, se genera el resultado independiente de su implementación y se
responde al consumidor [20].
Una definición formal de Web services, tomada del Consorcio W3C 69 , se cita a
continuación:
Definición: “Un Web Service es un sistema de software diseñado para
soportar interacción interoperable máquina-a-máquina sobre una red. Tiene
una interfaz descrita en formato de procesamiento de máquina
(específicamente WSDL). Otros sistemas interactúan con el Web Service de
manera preestablecida por su descripción utilizando mensajes SOAP,
normalmente sobre HTTP con una serialización XML. ” [19]
A continuación, en los numerales 1.1 y 1.2, se presentan los componentes y
características de los Web Services. En el numeral 1.3 se describen los diferentes
escenarios de implementación y finalmente en el numeral 1.4 se presenta la
arquitectura y estándares de los Web Services.
1.1. Componentes generales de los Web Services [21]
La arquitectura de los Web Services esta basada en la interacción de tres
componentes: un proveedor de servicios (Provider), un registro (Registry) y un
consumidor de servicios (Requestor); explicados en la Tabla 1 del numeral 3.2.1 del
presente documento. Estos componentes, a su vez, involucran las operaciones de
publicación, búsqueda e interacción entre ellos (ver Figura V).
Publicación: para poder ser accesible, la descripción de un servicio debe ser
publicada para que el consumidor de servicios pueda encontrarla.
W3C (World Wide Web Consortium) es una asociación internacional formada por organizaciones miembro
del consorcio, personal y el público en general, que trabajan conjuntamente para desarrollar estándares Web.
Su misión es “Guiar la Web hacia su máximo potencial a través del desarrollo de protocolos y pautas que
aseguren el crecimiento futuro de la Web”. Tomado de http://www.w3c.es/Consorcio/.
69
104
Búsqueda: el consumidor de servicios obtiene (encuentra) la descripción del
servicio directamente o hace consultas al registro del tipo de servicio requerido.
Interacción: eventualmente un servicio necesita ser invocado. En el proceso de
interacción el consumidor de servicios invoca o inicia una comunicación con un
servicio en tiempo de ejecución usando para ello la información contenida en la
descripción del servicio.
Figura V. Componentes de los Web Services.
1.2. Componentes funcionales Web Services [22]
Los componentes funcionales de los Web Services son mostrados en la Tabla I
Desarrollo de Servicios
(normas y reglas)
Seguridad
105
Otros Aspectos
Administración
Implementación(es)
(BPEL4WS) Business Process Execution
Service for Web Services
Universal Description, Discovery and
Integration (UDDI)
Web Service Description Language
(WSDL)
Simple Object Access Protocol (SOAP)/
Extensible Markup Language (XML)
Protocolo de
Hypertext Transfer Protocol (HTTP)
transferencia
Simple Mail Transfer Protocol (SMTP)
File Transfer Protocol (FTP)
Adaptado de Java Web Services Architecture [22]
Tabla I. Componentes funcionales Web Services.
Calidad de Servicio
(QoS)
Componente
Composición del
Servicio
Mecanismo de
Descubrimiento
Descripción de la
interfaz
Formato de los datos
A continuación se explica brevemente cada componente.
Composición del servicio
Aspecto más reciente concerniente a los Web Services. Se refiere a la habilidad de
combinar Web Services en los procesos de negocio.
La composición de servicios es la habilidad de secuenciar y manejar Web services para
convertirlos así en transacciones de mayor tamaño. Por ejemplo, una transacción que
añade a un cliente la cuenta de un banco debe también efectuar diferentes operaciones
como consecuencia. Todas estas solicitudes serian manejadas dentro del contexto de
una transacción de mayor tamaño que culmina o falla como una unidad (transparente
al usuario).
BPEL4WS provee un lenguaje para especificar formalmente procesos de negocio y
protocolos de interacción de negocio. Esto extiende el modelo de interacción de los
Web Services y permite que estos soporten transacciones de negocio.
Mecanismos de descubrimiento
Los Web Services soportan el concepto de descubrimiento dinámico de servicios donde
un consumidor utiliza un registro para encontrar los servicios en los cuales esta
interesado.
UDDI (Universal Description, Discovery and Integration) es el mecanismo de
descubrimiento para los Web Services. Para mas detalle de UDDI ver numeral 1.4.5.
Descripción de la interfaz
La descripción de la interfaz especifica aspectos como:



Operaciones que tiene a disposición el servicio.
Mensajes que el servicio acepta.
El protocolo que el consumidor debe seguir para poder acceder al servicio.
Los Web Services utilizan WSDL (Web Services Description Language) para especificar
el contrato de un servicio. Para mas detalle de WSDL ver numeral 1.4.4.
Formato de los Datos
Describe el formato en que los datos deben ser transferidos de un servicio a otro. XML
es el formato base utilizado para Web Services (ver numeral 1.4.2 para más detalle).
SOAP (Simple Object Access Protocol) es una especificación que le indica al
consumidor y proveedor de servicios como estructurar y leer un mensaje XML. Para
mas detalle de SOAP ver numeral 1.4.3.
Protocolo de Transferencia
106
La principal función del protocolo de transferencia es transportar datos de una maquina
a otra. Los Web Services utilizan múltiples protocolos de transferencia para
comunicarse servicio a servicio incluyendo HTTP, SMTP y FTP.
El protocolo más popular para uso en Web Services es HTTP, esto en parte a su
popularidad para transferencia de datos en la red mundial (World Wide Web) e
Internet. HTTP no es bloqueado por la gran mayoría de firewalls convirtiéndolo en el
estándar para la interoperabilidad de sistemas.
1.3. Escenarios de implementación [22]
Dado que un servicio puede ser desarrollado en diferentes tipos de plataformas, puede
también seguir diferentes modelos de implementación que son utilizados dependiendo
del problema a resolver. Los modelos de implementación de Web Services se pueden
agrupar en cuatro tipos: servicio simple, servicio compuesto, servicio middleware, y
servicio en bus.
Servicio simple
Un servicio simple es un componente, comúnmente un servlet, que pone a disposición
algún servicio para acceder directamente a una base de datos o a algún otro recurso.
Son comúnmente utilizados para el desarrollo de funciones pequeñas y discretas (Ver
figura VI).
Figura VI. Ejemplo de Servicio Simple
Servicio Compuesto
Un servicio compuesto hace uso de otros servicios simples o compuestos debido a que
muchos servicios requieren de otros para poder culminar su función (Ver Figura VII).
107
Figura VII. Ejemplo de servicio Compuesto.
Servicio Middleware
Un Web Service que pone solicitudes en el bus middleware es un ejemplo de una
implementación de servicio middleware. Muchas organizaciones tienen sistemas
middleware orientados a mensajes (MOM). Un sistema MOM consiste en que el emisor
coloca el mensaje en una cola y este es enrutado al punto final. El emisor no se entera
de la localización física o implementación del punto final (Ver Figura VIII).
Figura VIII. Ejemplo de un servicio Middleware.
Bus de Servicios
Conocido en la industria como ESB (Enterprise Service Bus). Este bus, al que se
refieren algunas veces como “orquestador de servicios”, provee integración y
conectividad de servicios de una forma más organizada, pero no más sencilla, que la
comunicación directa entre servicios. Su uso permite a las aplicaciones interoperar a
través de un eje común evitando así el “desorden” que se puede generar de una
comunicación directa entre servicios. La imagen de la Figura IX es un ejemplo de este
tipo de implementación.
108
Figura IX. Ejemplo de implementación bus de servicios.
1.4. Arquitectura y estándares de Web Services [20][24]
A continuación, en el numeral 1.4.1, se presenta el proceso de conexión y
descubrimiento de Web Services. Mas adelante en los numerales restantes, se de
describen detalladamente los componentes que conforman la estructura de los Web
services que son XML, SOAP, WSDL y UDDI.
1.4.1.
Proceso de conexión y descubrimiento [23]
A continuación se explica el proceso de conexión y descubrimientos de Web Services
(ver Figura X).
1. El proveedor de servicios crea el Web Service típicamente como interfaces de
servicio basados en SOAP para ser usado por aplicaciones del mercado. El
proveedor deposita la interface en un registro u contenedor de servicios, para
que esté disponible y pueda ser invocada sobre la red. El proveedor también
describe el Web Service por medio de un servicio de descripción basado en
WSDL que define los potenciales clientes y los servicios contenidos además de
la forma de identificar la localización del servicio, operaciones y modelo de
comunicación.
2. El proveedor de servicios registra la descripción del servicio basada en WSDL,
típicamente en un registro UDDI.
3. El registro UDDI almacena la descripción del servicio como plantillas
(descripción de la semántica) y conjuntos de URLs referidas a WSDLs
localizadas en el ambiente del proveedor.
4. El consumidor localiza el servicio haciendo consultas al registro UDDI. El
consumidor obtiene la plantilla correspondiente al servicio solicitado y las URLs
para identificar al proveedor.
109
5. Con las plantillas y las URLs el consumidor del servicio invoca al proveedor del
servicio obteniendo la descripción del servicio WSDL de los servicios
registrados. Luego el consumidor crea un cliente proxy y establece
comunicación con el proveedor por medio de mensajes SOAP.
6. Finalmente, el consumidor se comunica con el proveedor de servicios e
intercambia mensajes o datos invocando los servicios disponibles en el
contenedor de servicios.
Figura X. Proceso de conexión y descubrimiento Web Services.
110
Ciclo de vida de un Web Service
Figura XI. Ciclo de vida de un Web Service.
- Paso 1: El proveedor de servicios publica sus Web Services en un registro UDDI. En
este punto el proveedor crea la definición WSDL y publica un acceso a esta
definición (link) junto al resto de la información del Web Service en el registro
UDDI.
- Paso 2: Un consumidor de servicios localiza un Web Service obteniendo información
de cómo localizarlo de la definición WSDL publicada. Este paso involucra descargar
la definición WSDL al sistema del usuario y trasformarlo a Java (o cualquier otro
lenguaje). Esta interfaz java sirve como Proxy al Web Service y constituye la
información para poder interactuar con el Web Service.
- Paso
3: Las aplicaciones del usuario para enlazar el Web Service hacen uso de la
interfaz Java representando el WSDL como un Proxy.
- Paso
4: Finalmente, la aplicación usuario o el consumidor invoca el Web Service
basado en la información de invocación de servicios obtenida de la definición WSDL.
En este punto, haciendo uso del Proxy, se pueden invocar los métodos y funciones
expuestas por el Web Service.
1.4.2.
XML [25]
El World Wide Web Consortium (W3C) 70 comenzó a trabajar en XML (Extensible
Markup Language) a mediados de 1996 y publicó XML en su versión 1.0 en Febrero de
1998, dando solución a la necesidad de la industria de desarrollar un mecanismo
70
World Wide Web Consortium www.w3c.org.
111
simple pero extensible para la representación textual de información estructurada y
semi-estructurada. XML está basado en dos tecnologías que son SGML (Standard
Generalized Markup Language) y HTML; su objetivo principal es permitir que el SGML
genérico pueda ser enviado, recibido y procesado en la Web de una forma que ahora
es posible utilizando HTML [26].
XML forma parte de las tecnologías que hacen posible los Web Services ya que los
principales estándares que estos utilizan (SOAP,WSDL,UDDI) se basan en el.
A continuación se enuncian y describen brevemente algunos términos y conceptos
relacionados con XML.
XML 1.0
Es la especificación base sobre la cual está construida la familia XML. Describe la
sintaxis que los documentos XML deben seguir, las reglas que los traductores de XML
deben tener y todas las consideraciones que se deben tener para leer o escribir un
documento XML.
DTD (Document Type Definition)
Los DTDs permiten definir un conjunto de reglas relacionadas con el intercambio,
procesamiento y visualización de documentos XML en ambientes amplios como los
escenarios de Business to Business o comercio electrónico. El uso de DTDs permite
determinar que el documento XML sigue las reglas de sintaxis de la especificación XML
y que sigue las propias reglas de la persona que lo escribió en cuanto a contenido y
estructura.
Un documento XML no es muy utilizable sin un DTD (o schema) acompañante. Tal
como XML puede describir datos efectivamente, un DTD hace estos datos usables para
muchos programas en gran variedad de formas definiendo la estructura de los datos.
El DTD define el formato de los datos, que elementos están permitidos en un
documento XML, los atributos y posiblemente los valores y ocurrencias permitidos para
los atributos de cada elemento.
XML Schema
La especificación XML Schema es un meta lenguaje que describe la estructura de
documentos XML y el mapeo de la sintaxis XML a los tipos de datos. Fue creada para
cubrir algunas fallas de los DTDs en cuanto a la integración de espacios de nombre
(Namespaces), el diseño modular de vocabulario, modelos de contenido flexible y la
integración con aplicaciones orientadas a datos.
Esta especificación se divide en tres partes71:
XML Schema Parte 0, XML Schema Parte 1: Estructuras y XML Schema Parte 2: Tipos
de Datos.
71
World Wide Web Consortium. “XML Schema”. http://www.w3c.org/XML/Schema .
112
XSL72
XSL (Extensible Style sheet Language) es una familia de recomendaciones para definir
la transformación y presentación de un documento XML.
Consiste de tres partes: XSL Transformations (XSLT), XML Path Language (XPath) y
XSL Formatting Objects (XSL-FO).
XSL puede ser interpretado de dos formas:
- XSL es un lenguaje para transformar documentos XML.
- XSL es un vocabulario XML para especificar el formato de documentos XML.
Las dos interpretaciones son similares, pero una se encarga de transformar un
documento XML a otro formato, y la otra se centra en el contenido de cada
documento. Una definición mas clara es decir que XLS maneja las especificaciones de
cómo transformar un documento XML del formato A al formato B, donde los
componentes del lenguaje se encargan de identificar y procesar los constructores
necesarios para hacer esto.
XSLT73
XSLT (Extensible Style sheet Language for Transformations) es un lenguaje para
transformar documentos XML en otros documentos XML. Es diseñado para ser usado
como una parte de XSL.
XPath74
Describe un lenguaje de “query” para direccionar partes de un documento XML. Esto
permite que las aplicaciones puedan solicitar una parte específica de un documento
XML.
DOM75
DOM (Document Object Model) es un API que permite a las aplicaciones navegar en
documentos XML y manipular su contenido y estructura. El DOM define interfaces, no
implementaciones particulares; estas interfaces son especificadas usando IDL
(Interface Description Language). Generalmente se hace uso del DOM entre la
aplicación y el traductor de XML.
1.4.3.
72
73
74
75
World
World
World
World
SOAP [27]
Wide
Wide
Wide
Wide
Web
Web
Web
Web
Consortium.
Consortium.
Consortium.
Consortium.
“XSL”. http://www.w3c.org/Style/XSL/
“XSLT”. http://www.w3.org/TR/xslt
“XPath”. http://www.w3c.org/TR/xpath .
“Document Object Model”. http://www.w3c.org/DOM/
113
Es el acrónimo de Simple Object Access Protocol, es decir, protocolo simple de acceso
a objetos. SOAP es un protocolo ligero de mensajes XML que se usa para codificar la
información de los mensajes de petición y respuesta de los Web services, que se
envían a través de una red.
Los mensajes SOAP son independientes de los sistemas operativos y de los protocolos,
y pueden ser transportados usando una variedad de protocolos internet incluyendo
SMTP y HTTP.
Sus principales características son:
- Es un formato para el envío de mensajes sobre Internet.
- Es independiente de la plataforma.
- Es independiente del lenguaje.
- Está basado en XML lo que permite extensiones.
- Tiene menos restricciones de seguridad y de compatibilidad
que el mayor
procedimiento que se usa hoy en día para comunicación application-to-application
RPC (Remote Procedure Call); RPC utiliza para la invocación de objetos DCOM o
CORBA puertos dinámicos, mientras que SOAP sobre HTTP utiliza en puerto
estándar 80.
¿Que especifica SOAP?
- Un formato de mensaje para una comunicación unidireccional, describiendo como se
empaqueta la información en documentos XML.
- Un conjunto de convenciones para usar mensajes SOAP para implementar el patrón
de interacción RPC, definiendo como los clientes pueden invocar un procedimiento
remoto enviando un mensaje SOAP y como los servicios pueden responder enviando
otro mensaje al llamador.
- Un conjunto de reglas que una entidad procesadora de mensajes SOAP debe seguir,
definiendo en particular los elementos XML que una entidad debe leer y entender,
así como las acciones que debe tomar si no entiende el contenido. Reglas de
codificación de los datos.
- Una descripción de cómo se debe transportar un mensaje SOAP sobre HTTP y SMTP.
- Sintaxis y semántica para representar documentos XML como mensajes SOAP
estructurados.
Es importante tener claro que SOAP no es un lenguaje de programación o un
componente para construir aplicaciones de negocio. SOAP tiene como propósito ser
utilizado como un protocolo de comunicación portable para enviar y recibir mensajes
SOAP que tienen que ser creados y procesados por una aplicación.
Anatomía de un mensaje SOAP
114
Como ya se mencionó, SOAP define la estructura de un documento XML, reglas, y
mecanismos que pueden ser utilizados para hacer posible la comunicaciones entre
aplicaciones. No depende de algún tipo de lenguaje de programación o de una
plataforma específica.
A continuación se explica por medio de un ejemplo la sintaxis XML, reglas semánticas y
convenciones utilizadas en un mensaje SOAP.
El ejemplo muestra los mensajes de solicitud (Tabla II) y respuesta (Tabla III) de los
precios de un libro de un proveedor.
La solicitud SOAP acepta un parámetro String como el nombre del libro y regresa un
float como el precio del libro en una respuesta SOAP. El mensaje SOAP viaja en una
solicitud HTTP para obtener la información de www.wiley.com del libro Developing Java
Web Services.
POST /BookPrice HTTP/1.1
Host: catalog.acmeco.com
Content-Type: text/xml; charset=”utf-8”
Content-Length: 640
SOAPAction: “GetBookPrice”
<SOAP-ENV:Envelope
xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsi=”http://www.w3c.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3c.org/2001/XMLSchema”
SOAP-ENV:encodingStyle
=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<person:mail
xmlns:person=”http://acmeco.com/Header/”>[email protected]
om
</person:mail>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetBookPrice
xmlns:m=”http://www.wiley.com/jws.book.priceList”>
<bookname xsi:type=’xsd:string’>
Developing Java Web Services</bookname>
</m:GetBookPrice>
</SOAP-ENV:Body>
</SOAP-ENV: Envelope>
Tabla II. Mensaje de solicitud SOAP.
HTTP/1.1 200 OK
Content-Type: text/xml; charset=”utf-8”
Content-Length: 640
<SOAP-ENV:Envelope
xmlns:SOAPENV=http://schemas.xmlsoap.org/soap/envelope/
115
xmlns:xsi=”http://www.w3c.org/2001/XMLSchemainstance”
xmlns:xsd=”http://www.w3c.org/2001/XMLSchema”
SOAP-ENV:
encodingStyle=”http://schemas.xmlsoap.org/soap/encodi
ng/”/>
<SOAP-ENV:Header>
<wiley:Transaction
xmlns:wiley=”http://jws.wiley.com/2002/booktx”
SOAP-ENV:mustUnderstand=”1”>
</wiley:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetBookPriceResponse xmlns:m=”
http://www.wiley.com/jws.book.priceList”>
<Price>50.00</Price>
</m:GetBookPriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Tabla III. Mensaje de respuesta SOAP.
Un mensaje SOAP es un archivo XML con un elemento sobre (Envelope) que identifica
el archivo XML como un mensaje SOAP, un elemento encabezado (Header) que
contiene parámetros configurables con información adicional, un elemento cuerpo
(Body) que contiene la información verdadera de solicitud o respuesta y un elemento
opcional (Fault) que provee información de detección de errores ocurridos durante el
procesamiento del mensaje.
En los ejemplos ilustrados en la Tabla II y Tabla III se puede apreciar que los
mensajes SOAP contienen un SOAP Evelope SOAP-ENV:Envelope como su elemento
raíz principal. En el recae la definición de los XML Namespaces, comúnmente
identificados con la palabra clave xmlns, y especificar los prefijos para identificar los
elementos y sus reglas de codificación. Todos los elementos en el mensaje SOAP están
asociados a los namespaces definidos en el SOAP-ENV.
Toda aplicación SOAP debe incorporar y usar los namespaces SOAP relevantes para
definir los elementos y atributos en los mensajes enviados, e igualmente, debe ser
capaz de procesar los mensajes recibidos con estos namespaces específicos. Los
namespaces deben estar en un W3C XML Schema calificado, el cual facilita los
mensajes SOAP agrupando elementos utilizando prefijos y evitando la coalición de
namespaces.
Como se mostró en los ejemplos ilustrados en la Tabla II y Tabla III anteriores, la
estructura de un mensaje SOAP contiene cuatro elementos principales.
- Envelope.
- Header (Opcional).
- Body.
116
- Attachments(Opcional).
La Figura XII representa la estructura de un mensaje SOAP con attachments.
Figura XII. Estructura de un mensaje SOAP.
Comunicación SOAP
SOAP esta diseñado para la comunicación entre aplicaciones independientemente de la
plataforma y del lenguaje de programación en que estas estén implementadas. Para
habilitar la comunicación entre los nodos, SOAP soporta los siguientes modelos de
comunicación.
- SOAP
RPC: define un llamado remoto a un procedimiento basado en una
comunicación sincrónica donde los nodos SOAP mandan y reciben mensajes
utilizando métodos de solicitud y respuesta e intercambio de parámetros para luego
regresar el valor.
- SOAP MESSAGING. Define una comunicación dirigida a documentos donde los nodos
SOAP mandan y reciben documentos basados en XML utilizando mensajes
sincrónicos y asincrónicos.
1.4.4.
WSDL (Web Service Description Language) [6][23]
Microsoft, IBM y Ariba 76 publicaron la primera versión de WSDL en Septiembre de
2000, poco después de haber anunciado la especificación UDDI junto a 36 compañías
más. Esta versión WSDL estaba basada en dos lenguajes descriptivos precedentes:
NASSL (Network Accessible Services Specification Language) y SCL (SOAP Contract
Language). Luego en Marzo de 2001, las mismas compañías cedieron la especificación
76
Ariba: Empresa proveedora de servicios para empresas.
117
WSDL 1.1 al W3C. Oficialmente WSDL 1.1 es considerado la base de la especificación
WSDL 1.2 que esta trabajando en la actualidad el W3C.
WSDL, como se conoce actualmente, es un lenguaje descriptivo de Web Services. Esto
significa que WSDL representa información sobre la interfaz y semántica de cómo
invocar o llamar un Web Service. Una descripción WSDL contiene cuatro piezas
importantes de información respecto a Web Services.
- Información de la interfaz describiendo todas las funciones publicas disponibles.
- Información de los tipos de datos para los mensajes entrantes (solicitudes) y
los
mensajes salientes (respuestas).
- Información de interconexión (Binding) sobre los protocolos que se deben usar para
invocar un Web Service específico.
- Información de la dirección para localizar un Web Service específico.
Después de desarrollar un Web Service se procede a crear su especificación WSDL, lo
cual se puede hacer de manera manual o haciendo uso de una herramienta. Cuando la
definición WSDL es creada se publica un acceso a ella en un registro de Web Services
(basado en UDDI), de esta manera los potenciales usuarios de este Web Services
pueden seguir el acceso y encontrar la localización del Web Service, las funciones que
soporta y como invocar estas funciones. Finalmente, el usuario podrá usar esta
información para formular una solicitud SOAP, o cualquier tipo de solicitud basada en
los protocolos de interconexión soportados, para poder invocar las funciones de un
Web Service.
Anatomía de la definición de un documento WSDL
La definición de un documento WSDL esta conformada por los siguientes siete
elementos (ver Figura XIII).
- <definitions>:
Un documento WSDL es un conjunto de definiciones especificadas
dentro de la palabra clave <definitios>, que a su vez constituye el elemento raíz de
un documento WSDL. Define el nombre del Web Service y también los namespaces
que se utilizaran en el resto del documento WSDL.
- <types>:
Este elemento define todos los tipos de datos que serán utilizados para
describir los mensajes intercambiados entre el Web Service y el consumidor. WSDL
no define el uso de un sistema tipográfico específico, sin embargo XML Schema es
utilizado como sistema por defecto.
- <message>: Este elemento representa una definición lógica de los datos que serán
transmitidos entre el Web Service y el usuario. Describe un mensaje de una sola vía
(one - way), el cual puede representar una solicitud o una respuesta enviada a o
desde el Web Service. Puede estar vació o contener partes identificadas con la
palabra clave <part> las cuales se refieren a los parámetros de solicitud o a los
valores de respuesta.
118
- <portType>: Este elemento contiene las definiciones abstractas de las operaciones
soportadas por un Web Service, combinando varios mensajes de solicitud y
respuesta definidos por los elemento <message>. Cada operación se refiere a un
mensaje de entrada y uno de salida.
- <binding>:
Este elemento especifica un protocolo concreto y formatos de datos
utilizados para representar las operaciones y mensajes definidos por algun
<porType> particular. Todos los aspectos correspondientes a la comunicación SOAP
se encuentran contenidos en este elemento.
- <port>: Este elemento especifica una dirección para enlazar algún Web Service.
- <service>:
Este elemento agrega un conjunto relacionado de <port>. Un
<service> consistente de múltiples elementos <port>, representa la capacidad del
servicio de ser invocado sobre múltiples enlaces.
Figura XIII. Estructura de un documento WSDL.
1.4.5.
UDDI [23]
119
UDDI (Universal Description, Discovery, and Integration) provee un método
estandarizado para publicar y descubrir información acerca de Web Services. El
proyecto UDDI es una iniciativa de la industria para crear una plataforma
independiente y un sistema de soporte abierto para la descripción de servicios,
descubrimiento e integración de servicios. UDDI esta enfocado en el proceso de
descubrimiento en una arquitectura SOA.
Un registro UDDI contiene información referente a negocios y los servicios que ofrecen,
e información sobre especificaciones de la industria y servicios que soportan. Los
consumidores de servicios pueden buscar en un registro por negocios, servicios y tipos
de servicios, ya sea a través de programas autónomos o por medio de una interfaz
basada en Web.
¿Qué es un Registro?
Es aquel que provee la habilidad a los consumidores de servicios para localizar
fácilmente las entidades de negocio deseadas y los servicios que estas proveen.
Existen tres secciones para el registro de un servicio: las páginas amarillas que
describen la compañía que ofrece el servicio (nombre, dirección, etc.), las páginas
blancas que incluyen categorías industriales basadas en taxonomías estándar tales
como el Sistema Norte Americano de Clasificación de Industrias y el estándar de
clasificación de industrias, y por último las páginas verdes describen la interfaz de los
servicios de forma detallada.
Especificaciones UDDI
La especificación UDDI 2.077 incluye los siguientes documentos.
- Replicación
UDDI: Este documento describe el proceso de replicación de datos e
interfaces que un operador de registro debe conformar para llevar a cabo la
replicación de datos entre sitios.
- Operadores
UDDI: Este documento provee información sobre el comportamiento
operacional que debe ser seguido por los operadores de nodos UDDI. Por ejemplo.
El documento define las líneas guía que los operadores pueden seguir para manejar
la información de los nodos de registro UDDI. Algunas de estas líneas incluyen:



Los operadores de los nodos son los responsables de la durabilidad de
protección de los datos.
Validar la información provista por las entidades de negocio durante el
proceso de registro, por ejemplo la dirección de e-mail.
Verificar la integridad de los datos en el registro UDDI después de alguna
modificación. Por ejemplo si alguna entidad fue borrada del registro, el
operador debe asegurar que los servicios correspondientes a esa entidad
también sean borrados.
Todas las versiones de la especificación UDDI pueden ser obtenidas de la organización UDDI en su sitio
Web http://uddi.org/specification.html.
77
120
- Api
UDDI para programadores: Este documento describe las interfaces de
programación soportadas por un registro UDDI en términos de mensajes SOAP.
- Estructuras
de datos UDDI: Este documento describe los detalles de las
estructuras XML asociadas a un mensaje SOAP y utilizadas para comunicarse con el
registro UDDI.
Comunicación registro UDDI
La especificación UDDI define dos APIs basados en XML para poder comunicarse con el
registro UDDI: API de consulta y API de publicación.
- API de consulta
Consiste en mensajes XML definidos utilizando UDDI Schema, y es utilizado para
localizar información sobre una entidad de negocio, junto con los servicios ofrecidos y
la especificación técnica de los mismos (documentos WSDL).
La siguiente es una lista de las funciones de consulta utilizadas para encontrar
información en un registro UDDI.





<find_business>
<find_relatedBusinesses>
<find_service>
<find_binding>
<find_tModel>
Para obtener información mas detallada del registro se pueden utilizar las siguientes
funciones.





<get_businessDetail>
<get_businessDetailExt>
<get_serviceDetail>
<get_bindingDetail>
<get_tModelDetail>
- API de publicación
Consiste en funciones representadas por un UDDI Schema las cuales definen mensajes
XML que pueden ser utilizados para crear, actualizar, y borrar la información presente
en un registro UDDI. Para poder publicar en un registro UDDI el usuario del registro
necesita ser autenticado. La siguiente es una lista de funciones que pueden ser
utilizadas para adicionar / modificar información en un registro UDDI.






<save_business>
<set_publisherAssertions>
<add_publisherAssertions>
<save_service>
<save_binding>
<save_tModel>
121
La siguiente es una lista de funciones del API que pueden ser utilizadas para borrar
información del registro UDDI.





<delete_business>
<delete_publisherAssertions>
<delete_service>
<delete_binding>
<delete_tModel>
Aparte de las funciones ya mencionadas los APIs definen funciones que manejan la
autenticación de los usuarios del registro.


<get_authToken>
<discard_authToken>
Los mensajes XML son contenidos en mensajes SOAP y enviados al registro UDDI, en
otras palabras, todos los mensajes XML son codificados por medio de un elemento
SOAP (<body>) y enviados a través de una solicitud HTTP al registro UDDI. El registro
UDDI procesa el mensaje SOAP que recibe identificando el tipo de función contenida en
el mensaje XML y notificando al registro si es un servicio de publicación o de consulta.
Un nodo de registro UDDI provee ambas funcionalidades, publicación y consulta,
ambas a través de diferentes puntos de acceso o URLs. La Tabla IV muestra algunas
URLs de registros UDDI para publicación y consulta.
Operador
HP
IBM
Production
URL de Consulta
http://uddi.hp.com/inquire
http://www3.ibm.com/services/uddi/inquiryapi
IBM Test
http://www3.ibm.com/services/uddi/testregistry/in
quiryapi
http://uddi.microsoft.com/inquire
Microsoft
Production
Microsoft
Test
SAP Test
Systinet
http://test.uddi.microsoft.com/inquire
http://udditest.sap.com/UDDI/api/inquir
y/
http://www.systinet.com/wasp/uddi/inq
uiry/
URL de Publicación
https://uddi.hp.com/publish
https://www3.ibm.com/services/uddi/protect/publi
shapi
https://www3.ibm.com/services/uddi/testregistry/p
rotect/publishapi
https://uddi.microsoft.com/publish
https://test.uddi.microsoft.com/publis
h
https://udditest.sap.com/UDDI/api/pu
blish/
https://www.systinet.com/wasp/uddi/
publishing/
Tabla IV. URLs de consulta y publicación.
Estructura de datos UDDI
La información manejada por un registro UDDI es representada como estructuras de
datos XML o también conocidas como estructuras de datos UDDI. La especificación
UDDI define el significado de estas estructuras de datos y la relación entre ellas y los
usuarios de un registro UDDI trabajan primordialmente con estas estructuras. Un
122
cliente UDDI hace uso de estas estructuras en conjunto con los mensajes XML para
poder manipular información especifica en un registro.
Las siguientes son las estructuras primarias manejadas en un registro UDDI.
- <businessEntity>
- <publisherAssertion>
- <businessService>
- <bindingTemplate>
- <tModel>
Todas estas estructuras de datos, excepto <publisherAssertion>, son identificadas y
referenciadas por medio de un identificador de 128 – bits global llamado UUID (Unique
Identifier). Estos UUIDs pueden ser usados como llaves para acceder datos específicos
dentro de un registro.
A continuación se describen brevemente las estructuras de datos de un registro (Ver
Figura XIV).

<businessEntity>: Representa la información principal respecto a un negocio,
por ejemplo, información de contacto, categorización del negocio respecto a
una taxonomia específica o Schema de clasificación, identificadores, relación
con otras entidades de negocio, entre otros.

<publisherAssertion>: Un negocio inscrito en un registro UDDI puede tener
relaciones activas con otros negocios. Estas relaciones pueden ser de diferentes
formas, por ejemplo, un relación business to customer, las cuales son
representadas por una estructura de datos <publisherAssertion> en el registro
UDDI. La estructura <publisherAssertion> es utilizada para establecer relación
entre dos estructuras <businessEntity>.

<businessService>: Representa los servicios de un negocio, estos pueden ser
Web Services o cualquier otro tipo de servicios. La estructura
<businessService> es la representación lógica de los servicios que un negocio
tiene para ofrecer.

<bindingTemplate>: Consiste en apuntadores a descripciones técnicas y
puntos de acceso URLs de servicios. La estructura <bindingTemplate> no
provee especificaciones detalladas del servicio.

<tModel>: Provee la descripción de una especificación particular o
comportamiento del servicio. La estructura <tModel> no contiene la
especificación del servicio directamente, contiene un link a la misma.
123
Figura XIV. Estructuras de datos de un registro UDDI.
ANEXO 4. Plataforma J2EE
En los siguientes numerales se describen brevemente los conceptos y definiciones
relacionados con la plataforma J2EE.
1. Introducción a J2EE [33]
Las arquitecturas orientadas a servicios están fundamentalmente construidas sobre
infraestructuras que permiten a los desarrolladores encapsular funcionalidades de
negocio en componentes reusables que son publicadas a través de interfaces bien
definidas. J2EE facilita este concepto separando claramente los interesados en su
arquitectura (concerns), un conjunto de estándares para desarrollar la capa de
presentación de la aplicación, otro conjunto para desarrollo e integración que
constituyen la capa de negocio, y por último un conjunto bien definido de
infraestructuras de servicio incluyendo transacciones, seguridad, conectividad y
servicios de ciclo de vida.
La plataforma J2EE utiliza un modelo de aplicación multicapas distribuido para
aplicaciones empresariales. Los componentes que conforman una aplicación J2EE son
instalados en diferentes máquinas dependiendo de la capa en el ambiente multicapas
J2EE a la cual pertenezcan.
La Figura XV muestra dos aplicaciones
continuación.
divididas en las capas que se listan a
- Capa-Cliente: los componentes residen en la maquina del cliente.
- Capa-Web: los componentes residen en el servidor J2EE.
- Capa-Negocio: los componentes residen en el servidor J2EE.
- Capa EIS (Enterprise Information System): los componentes residen en el servidor
EIS.
124
Figura XV. Aplicaciones multicapa J2EE.
Aunque las aplicaciones J2EE pueden consistir de las tres o cuatro capas mostradas en
la figura XV, las aplicaciones multicapa J2EE son generalmente consideradas
aplicaciones de tres capas por que están distribuidas en tres lugares específicos:
maquina cliente, maquina servidor J2EE y la máquina que contiene la información o
base de datos.
2. Componentes J2EE
Las aplicaciones J2EE están conformadas de componentes. Un componente J2EE es
una unidad de software funcional auto-contenido, adicionado a una aplicación con sus
clases y archivos relacionados que le permiten comunicarse con otros componentes. La
especificación J2EE define los siguientes componentes:
- Las
aplicaciones cliente junto a los applets son componentes que residen en el
cliente.
- Las tecnologías Java
Servlet y JSP (JavaServer Pages) son componentes Web que
residen en el servidor.
- EJB (Enterprise JavaBeans) son componentes de negocio que residen en el servidor.
Los componentes J2EE son escritos en el leguaje de programación Java y son
compilados en la misma forma que cualquier otro programa escrito en este lenguaje.
La diferencia entre los componentes J2EE y las clases Java estándar es que los
componentes J2EE son agregados a aplicaciones J2EE, su estructura es verificada y se
asegura que cumplan con la especificación J2EE, luego son desplegados para su
producción, donde son ejecutados y manejados por el servidor J2EE.
A continuación se detallan los componentes J2EE existentes en cada capa.
Componentes Cliente
125
- Tipos de cliente
Un cliente J2EE puede ser Web o una aplicación.

Cliente Web
Un cliente Web consiste en dos partes:
(1) Paginas Web dinámicas que contienen varios tipos de lenguajes de marcas
(HTML, XML, entro otros) generados por componentes Web residentes en la
capa Web, y
(2) Un navegador Web encargado de administrar las páginas recibidas del
servidor.
Los clientes Web son a menudo denominados clientes ligeros. Los clientes
ligeros no hacen consultas directas a la base de datos, no ejecutan reglas de
negocio complejas ni heredan a otras aplicaciones. Cuando se usa clientes
ligeros las operaciones de este tipo (heavyweight) son delegadas a EJBs
residentes en el servidor J2EE, donde pueden gestionar aspectos de seguridad,
rendimiento, servicio y disponibilidad de las tecnologías J2EE contenidas en el
servidor.

Applets
Una página Web recibida de la capa Web puede incluir un applet. Un applet es
una aplicación cliente pequeña escrita en el leguaje de programación Java que
se ejecuta en la maquina virtual de Java instalada en el navegador Web.

Aplicaciones cliente
Proveen al cliente una forma de manejar tareas que requieren una interfaz
más rica que puede ser provista por lenguajes de marcas. Típicamente utilizan
una interfaz grafica de usuario (GUI).
Las aplicaciones cliente acceden directamente a los enterprise beans alojados
en la capa de negocio. Sin embargo, si los requerimientos de la aplicación lo
permiten, una aplicación cliente puede abrir una conexión HTTP para
establecer comunicación con un Servlet alojado en la capa Web.
Las aplicaciones J2EE hace uso de browsers basados en clientes ligeros (thin
client) o clientes robustos (thick client). La decisión de cual de los dos utilizar
depende de que ventajas ofrezca mantener la funcionalidad en el cliente y cercana
al usuario (thin client) o migrar toda la funcionalidad posible al servidor (thin
client). Entre mas funcionalidad sea migrada al servidor es mas fácil distribuir,
depositar y manejar la aplicación, sin embargo, mantener la funcionalidad en el
cliente puede hacer mas enriquecedora la experiencia del usuario.
- Comunicación con el servidor J2EE
126
La figura XVI muestra algunos de los componentes que pueden constituir la capa
cliente.
El cliente se comunica directamente con la capa de negocio contenida en el servidor
J2EE o, siendo el caso de un cliente browser, se comunica con páginas JSP o
Servlets contenidos en la capa Web.
Figura XVI. Capa cliente.
Componentes Web
Los componentes Web J2EE contemplan los Servlets y las páginas creadas utilizando
tecnologías JSP (paginas JSP). Los Servlets son clases programadas en lenguaje Java
que procesan solicitudes y construyen respuestas dinámicamente. Las páginas JSP son
documentos basados en texto que se ejecutan como Servlets pero permiten una
aproximación más natural para crear un contenido estático.
Las páginas HTML estáticas y los applets son ligados con los componentes Web
durante el ensamblado de la aplicación pero no son considerados componentes Web
por la especificación J2EE.
Como se muestra en la Figura XVII la capa Web, al igual que la capa cliente, pueden
incluir componentes Java Beans para manejar las entradas y enviar la información a
los enterprise beans contenidos en la capa de negocio y encargados del proceso de la
información.
127
Figura XVII. Capa Web.
Componentes de negocio
El código de negocio, consiste en la lógica que resuelve o enfrenta las necesidades de
dominios de negocios particulares como el financiero, bancario, especializado, etc. Es
manejado por los enterprise beans alojados en la capa de negocio. La figura XVIII
muestra como un enterprise bean recibe información del programa cliente, la procesa
(si es necesario) y la transmite al la capa encargada del almacenamiento EIS (enter
prise information system).
Figura XVIII. Capa de Negocio.
Existen tres tipos de enterprise beans: de sesión (session beans), de entidad (entity
beans) y manejadores de mensajes (message driven beans).
- Session
Bean: Representa una conversación transitoria con el cliente. Cuando el
cliente termina de ejecutarse el session bean y la información relacionada
desaparece.
128
- Entity
Bean: Representa información persistente almacenada en una tabla de la
base de datos. Si el cliente termina o el servidor queda fuera de línea, los servicios
subyacentes aseguran que la información del Entity Bean sea salvada.
- Message Driven Bean: Combina características de los Session Beans con JMS (Java
Message Service) permitiendo a los componentes de negocio recibir mensajes JMS
asincrónicamente.
3. Contenedores J2EE
Normalmente las aplicaciones cliente ligeras multicapa son complicadas de escribir
debido a que implican gran numero de líneas de código para manejar las
transacciones, el estado, la administración y asignación de recursos, el acceso
concurrente (multi-hilo) y otros aspectos complejos de bajo nivel. La arquitectura
J2EE basada en componentes e independiente de la plataforma, hace posible que las
aplicaciones J2EE sean fáciles de escribir debido a que la lógica es organizada en
componentes reutilizables. Adicionalmente, el servidor J2EE provee servicios
subyacentes en la forma de un contenedor para cualquier tipo de componente. No es
prioritario para el desarrollador concentrarse en estos servicios, J2EE se encarga de
lidiar con estos aspectos y permite que el usuario se concentre en solucionar su
problema.
Contenedores de Servicios
Los contenedores son la interfaz intermedia entre los componentes y las
funcionalidades de bajo nivel específicas de la plataforma que soportan a los
componentes. Antes que un componente Web, un enterprise bean o un componente de
una aplicación cliente pueda ser ejecutado, debe ser ensamblado en un modulo J2EE y
depositado en su respectivo contenedor.
El proceso de ensamble involucra especificar características únicas en el contenedor
para cada componente. La configuración del contenedor personaliza los procesos
subyacentes soportados y provistos por el servidor J2EE, incluyendo aspectos como
seguridad, manejo de transacciones, JNDI (Java Naming and Directory Interface) y
conectividad remota. Algunas de las características que provee J2EE son:
- El
modelo de seguridad J2EE permite configurar un componente Web o enterprise
bean para que los recursos del sistema sean accedidos únicamente por usuarios
autorizados.
- El
modelo de transacciones de J2EE permite especificar la relación entre métodos
que realizan transacciones simples de tal forma que todos los métodos en una
transacción son tratados como una unidad.
- El servicio JNDI provee una interfaz unificada para localizar información en distintos
directorios distribuidos.
- El modelo de conectividad remota de J2EE maneja todos los aspectos de bajo nivel
que permiten la comunicación entre el cliente y los enterprise beans. Después de
que un enterprise bean es creado los clientes invocan métodos de él como si
estuviese en la misma maquina virtual.
129
Tipos de contenedores
El proceso de despliegue (deploy) instala componentes de aplicaciones J2EE en los
contenedores J2EE ilustrados en la figura XIX.
Figura XIX. Servidor y contenedores J2EE.
- Servidor J2EE: Porción en ejecución de los productos J2EE. Un servidor J2EE provee
contenedores Web y contenedores para EJB’s.
- Contenedor
Web: Maneja la ejecución de las paginas JSP y los Servlets de las
aplicaciones J2EE. Los componentes Web y su contenedor residen en el servidor
J2EE.
- Contenedor
para EJBs (Enterprise Java Beans): Maneja la ejecución de los
enterprise beans de las aplicaciones J2EE. Los enterprise beans y su contenedor
residen en el servidor J2EE.
- Contenedor de las aplicaciones Cliente: Maneja la ejecución de los componentes de
las aplicaciones cliente. Las aplicaciones cliente junto con su contenedor corren en
el cliente.
- Contenedor
de Applets: Manejan la ejecuciones de los applets. Consisten en un
navegador Web (Web browser) y complementos de Java residentes en el cliente.
4. Tecnologías J2EE
EJB (Enterprise JavaBean)
Un componente EJB es una estructura de código que contiene campos y métodos cuya
función es implementar módulos de lógica de negocio. Se puede pensar en los
enterprise beans como bloques de código que pueden ser utilizados por separado o en
conjunto para ejecutar lógica de negocio en el servidor J2EE. Los enterprise beans a
menudo interactúan con las bases de datos.
130
Existen tres tipos de enterprise beans: session bean, entity bean y message driven
bean.
Uno de los beneficios de utilizar entity beans es que el desarrollador no se debe
preocupar por escribir sentencias SQL o por utilizar el API JDBC para acceder a la base
de datos pues el contenedor EJB se encarga de ello.
Tecnología Java Servlet.
Nos permiten definir clases HTTP específicas. Una clase perteneciente a un servlet
permite extender la capacidad de los servidores que almacenan aplicaciones que son
accedidas por un modelo de programación solicitud – respuesta. Si embargo los
Servlets pueden responder cualquier tipo de solicitud y son a menudo utilizados para
extender las aplicaciones contenidas en el servidor Web.
JSP (JavaServer Pages).
Nos permite colocar fragmentos de código de un Servlet directamente en un
documento basado en texto. Un JSP es un documento basado en texto que contiene
dos tipos de texto: información estática (puede ser expresada en cualquier formato
basado en texto como HTML, WML, o XML) y elementos JSP, los cuales determinan
como la pagina construye contenido dinámico.
JMS (Java Message Services).
Estándar de mensajes que permite a los componentes de las aplicaciones J2EE crear,
enviar, recibir e interpretar mensajes. Hace posible la comunicación distribuida poco
acoplada, confiable y asincrónica.
JTA (Java Transaction API).
Nos provee una interfaz estandarizada para gestionar transacciones. La arquitectura
J2EE provee un auto commit por defecto para el manejo de los commit y los rollback
de las transacciones. Un auto commit significa que cualquier otra aplicación que haga
uso de los datos vera la información actualizada después de una operación de escritura
o lectura sobre la base de datos.
JavaMail API.
Las aplicaciones J2EE utilizan el JavaMail API para enviar notificaciones de e-mail. El
Java-Mail API posee dos partes: una interfaz a nivel de aplicación utilizada por los
componentes de la aplicación para el envió de correos, y una interfaz a nivel de
proveedor de servicios. La plataforma J2EE incluye JavaMail con un proveedor de
servicios permitiéndole a los componentes de la aplicación enviar correos por Internet.
JAF (JavaBeans Activation Framework)
Es incluido por que el JavaMail API lo utiliza. Provee un servicio estandarizado para
determinar el tipo de un fragmento arbitrario de datos, encapsular el acceso a ellos,
descubrir las operaciones que se pueden efectuar sobre ellos y crear el componente
JavaBean adecuado para hacer posibles esas operaciones.
131
(Java API para el procesamiento de XML
Conocido como JAXP (Java API for XML Processing) soporta el procesamiento de
documentos XML utilizando DOM (Documento Object Model), SAX (Simple API for
XML), y XSLT (Extensible Stylesheet Language Transformations). JAXP le permite a las
aplicaciones analizar y transformar documentos XML independientemente de una
implementación particular para el procesamiento de XML.
Java API para RPC basado en XML
JAX-RPC (The Java API for XML-based RPC) utiliza el estándar SOAP y HTTP
permitiendo que los programas clientes efectúen llamados a procedimientos remotos
(RPC) basados en XML. JAX-RPC también soporta WSDL permitiendo importar y
exportar documentos WSDL. Con JAX-RPC y WSDL es fácil ínter operar con clientes y
servicios residentes en plataformas basadas o no basadas en JAVA como .NET.
JAX-RPC confía en el protocolo HTTP permitiendo crear aplicaciones de servicios que
combinan HTTP con versiones Java de SSL (Secure Socket Layer) y TLS (Transport
Layer Security) para establecer autenticación básica o mutua. SSL y TLS aseguran la
integridad de los mensajes proveyendo ciframiento de la información y opciones de
autenticación tanto para el cliente como para el servidor.
SAAJ (SOAP with Attachments API for Java).
API de bajo nivel del cual depende JAX-RPC. SAAJ permite la producción y consumo de
mensajes SOAP.
JAXR (Java API for XML Registries)
Nos permite acceder registros de negocios y de propósito general a través de la Web.
Soporta estándares de registro y repositorio ebXML78, y la especificación UDDI.
API JDBC
Nos permite invocar comandos SQL desde métodos programados en Java. El API JDBC
es utilizado en un enterprise bean cuando se ignora el administrador de la persistencia
residente por defecto en el contenedor o cuando se tiene un session bean encargado
de acceder a la base de datos. Con el administrador de la persistencia residente en el
contenedor las operaciones de acceso a la base de datos son manejadas por el
contenedor y las implementaciones de los enterprise beans no contienen código JDBC
o sentencias SQL. El API JDBC también puede ser utilizado desde un Servlet o una
pagina JSP para acceder a la base de datos directamente sin necesidad de pasar por
un enterprise bean.
El API JDBC se divide en dos partes: una interfaz a nivel de aplicación utilizada por los
componentes de la aplicación para acceder a la base de datos, y una interfaz de
proveedor de servicios para adjuntar un controlador JDBC a la plataforma J2EE.
78
ebXML: Electronic Business using eXtensible Markup Language.
132
JNDI (Java Naming and Directory Interface)
Provee servicio de nombres y funcionalidades de directorio. Permite asociar atributos
con objetos y buscar objetos utilizando sus atributos. Utilizando JNDI las aplicaciones
J2EE pueden almacenar y recuperar cualquier tipo de objeto previamente nombrado.
El servicio de nombres J2EE
o a los componentes Web,
nombres hace posible que
acceder o cambiar el código
le permite a las aplicaciones cliente, a los enterprise beans
acceder a un entorno de nombres JNDI. Un entorno de
los componentes sean personalizados sin necesidad de
fuente de los mismos.
JAAS (Java Authentication and Authorization Service)
Provee una forma por medio de la cual las aplicaciones J2EE pueden autenticar y
autorizar usuarios específicos, o grupos de usuarios, para hacer uso de ellas.
ANEXO 5. Documentación de casos de uso
CASO DE USO # 1
Objetivo en contexto
Alcance y nivel
Precondiciones
Poscondiciones de éxito
Poscondiciones de fallo
Actores
secundarios
Disparador
primarios
Flujo de eventos
y
Ingresar a la aplicación.
Permite a los usuarios del sistema ingresar a la
aplicación.
Transferencia de fondos BanRep
El sistema debe tener registrado al usuario, el usuario
debe haber ingresado el nombre de usuario y
contraseña, el sistema debe haber autenticado al
usuario.
El usuario logra ingresar a la aplicación.
El usuario no ingresa a la aplicación debido a que la
información suministrada por el mismo no es
correcta.
El usuario no logra ingresar debido a un fallo a nivel
de comunicación.
Actor primario: Usuario del Sistema.
El usuario selecciona la transferencia de Fondos
BanRep en la pantalla de Aplicaciones BanRep.
2. El usuario selecciona la transferencia de Fondos
BanRep en la pantalla de Aplicaciones BanRep.
3. El sistema solicita la contraseña del usuario.
4. El usuario ingresa la información solicitada.
5. El sistema despliega las operaciones que el
usuario puede efectuar para la aplicación
133
transferencia de fondos BanRep.
4.1 El sistema despliega las operaciones de
consignación, retiro, transferencia de fondos y
consultas.
Sub-Variaciones
CASO DE USO # 2
Objetivo en contexto
Alcance y nivel
Precondiciones
Poscondiciones de éxito
Poscondiciones de fallo
Actores
primarios
secundarios
Disparador
Flujo de eventos
Sub-Variaciones
CASO DE USO # 3
Objetivo en contexto
y
Validar Usuario.
Permite a los usuarios autenticarse y verificar si el
usuario existe y tiene cuentas inscritas en la base de
datos.
Transferencia de fondos BanRep
El sistema debe tener registrado al usuario, el usuario
debe haber ingresado el nombre de usuario y
contraseña, el usuario debe haber suministrado la
cedula.
El usuario es autenticado, se confirma la existencia
del usuario en la base de datos, y las cuentas
inscritas.
El usuario no es validado debido a que la información
suministrada por el mismo no es correcta.
El usuario no logra ser validado debido a un fallo a
nivel de comunicación.
El usuario no logra ser validado debido a que el
sistema PKI Entrust fallo.
Actor primario: Usuario del Sistema.
El usuario intentar ingresar a la aplicación.
1. El usuario intenta acceder a la aplicación.
2. El sistema solicita el nombre de usuario y la
contraseña.
3. El sistema autentica al usuario.
4. El usuario ingresa a la aplicación.
5. El sistema solicita la cedula del usuario.
6. El sistema verifica la existencia de usuario y las
cuentas inscritas en la base de datos.
7. El usuario ingresa los datos solicitados.
8. El sistema verifica la existencia del usuario en la
base de datos.
3.1 El sistema autentica al usuario invocando al
Servicio Web esRoaming y suministrándole el
nombre de usuario y contraseña ingresados.
6.1 El sistema verifica la existencia del usuario
haciendo una búsqueda en la base de datos
utilizando como llave primaria la cedula
suministrada y obteniendo las cuentas inscritas.
Transferir Fondos.
Permite a los usuarios efectuar transferencias entre
134
Alcance y nivel
Precondiciones
Poscondiciones de éxito
Poscondiciones de fallo
Actores
secundarios
Disparador
primarios
Flujo de eventos
Sub-Variaciones
CASO DE USO # 4
Objetivo en contexto
Alcance y nivel
Precondiciones
Poscondiciones de éxito
y
cuentas propias y cuentas asociadas.
Transferencia de fondos BanRep
El sistema debe tener registrado al usuario, el usuario
debe haber ingresado a la aplicación de transferencia
de fondos BanRep.
El usuario efectúa la transferencia de fondos
exitosamente.
El usuario no concreta la transferencia debido a que
la información suministrada por el mismo no es
correcta.
El usuario no concreta la transferencia debido a un
fallo a nivel de comunicación.
El usuario no concreta la transferencia debido a un
fallo en la base de datos de la aplicación.
Actor primario: Usuario del Sistema.
El usuario selecciona la operación de transferencia de
fondos.
1. El usuario selecciona la operación de transferencia
de fondos.
2. El sistema solicita el número de cuenta origen.
3. El sistema solicita el tipo de cuenta destino.
4. El sistema solicita el número de cuenta destino y
el monto a transferir.
5. El sistema efectúa la transferencia.
6. El usuario recibe un mensaje de confirmación si la
transferencia es exitosa, en caso contrario recibe
un mensaje de error.
2.1 Para transferir fondos el usuario solo puede
efectuar
esta
operación
desde
cuentas
personales.
2.1 La cuenta destino para una transferencia de
fondos puede ser personal si es una cuenta del
mismo usuario o asociada si es una cuenta de
otro usuario, las cuentas asociadas deben estar
previamente inscritas.
5.1 El sistema invoca el Servicio Web de firma digital
(registrar visor) para firmar la operación de
transferencia de fondos, esta operación firmada
es almacenada en la base de datos de la
aplicación.
Retirar.
Permite a los usuarios retirar de cuentas personales.
Transferencia de fondos BanRep
El sistema debe tener registrado al usuario, el usuario
debe haber ingresado a la aplicación de transferencia
de fondos BanRep.
El usuario efectúa un retiro exitoso de una cuenta
135
Poscondiciones de fallo
Actores
primarios
secundarios
Disparador
Flujo de eventos
y
El usuario selecciona la operación de retiro.
1. El usuario selecciona la operación de retiro.
2. El sistema solicita el número de cuenta origen.
3. El sistema solicita el monto a retirar.
4. El sistema efectúa el retiro.
5. El usuario recibe un mensaje de confirmación si el
retiro es exitoso, en caso contrario recibe un
mensaje de error.
2.1 La cuenta suministrada por el usuario para un
retiro debe ser personal.
4.1 El sistema invoca el Servicio Web de firma digital
(registrar visor) para firmar la operación de
retiro, esta operación firmada es almacenada en
la base de datos de la aplicación.
Sub-Variaciones
CASO DE USO # 5
Objetivo en contexto
Alcance y nivel
Precondiciones
Poscondiciones de éxito
Poscondiciones de fallo
Actores
primarios
secundarios
Disparador
Flujo de eventos
propia.
El usuario no concreta el retiro debido a que la
información suministrada por el mismo no es
correcta.
No se concreta el retiro debido a un fallo a nivel de
comunicación.
No se concreta el retiro debido a un fallo en la base
de datos de la aplicación.
Actor primario: Usuario del Sistema.
y
Consignar.
Permite a los usuarios consignar a cuentas propias y
asociadas.
Transferencia de fondos BanRep
El sistema debe tener registrado al usuario, el usuario
debe haber ingresado a la aplicación de transferencia
de fondos BanRep.
El usuario efectúa una consignación exitosamente.
El usuario no concreta la consignación debido a que
la información suministrada por el mismo no es
correcta.
No se concreta la consignación debido a un fallo a
nivel de comunicación.
No se concreta la consignación debido a un fallo en la
base de datos de la aplicación.
Actor primario: Usuario del Sistema.
El usuario selecciona la operación de consignación.
1. El
usuario
selecciona
la
operación
de
consignación.
2. El sistema solicita el tipo de cuenta.
3. El sistema solicita el número de cuenta.
4. El sistema solicita el monto a consignar.
5. El sistema efectúa la consignación.
136
6. El usuario recibe un mensaje de confirmación si la
consignación es exitosa, en caso contrario recibe
un mensaje de error.
2.1 El tipo de cuenta para una consignación puede
ser propia o asociada.
5.1 El sistema invoca el Servicio Web de firma digital
(registrar visor) para firmar la operación de
consignación,
esta
operación
firmada
es
almacenada en la base de datos de la aplicación.
Sub-Variaciones
CASO DE USO # 6
Objetivo en contexto
Alcance y nivel
Precondiciones
Poscondiciones de éxito
Poscondiciones de fallo
Actores
secundarios
Disparador
primarios
Flujo de eventos
Sub-Variaciones
CASO DE USO # 7
Objetivo en contexto
Alcance y nivel
Precondiciones
y
Registrar Log.
Permite llevar un registro de las operaciones
efectuadas, y los Servicios Web invocados.
Transferencia de fondos BanRep – visor.
El sistema debe tener registrado al usuario, el usuario
debe haber ingresado a la aplicación de transferencia
de fondos BanRep.
El log es realizado y almacenado en la base de datos
del visor.
El log no se puede efectuar debido a un fallo a nivel
de comunicación.
El log no se puede efectuar debido a un fallo en la
base de datos del visor.
Actor primario: Usuario del Sistema – Auditor.
Si se efectúa una operación de consignación, retiro o
transferencia de fondos.
1. El usuario selecciona la operación deseada.
2. El sistema efectúa el log de la operación.
3. El log es almacenado en la base de datos del
Visor.
2.1 Para efectuar el log de la operación el sistema
invoca
al
servicio
Web
FirmarDigitalmenteMensaje, una ves firmada la
operación se invoca al servicio Web de
RegistarVisor para almacenar la firma en la base
de datos del Visor.
Realizar Consulta.
Permite a los usuarios efectuar consultas sobre el
estado de sus cuentas.
Transferencia de fondos BanRep
El sistema debe tener registrado al usuario, el usuario
debe haber ingresado a la aplicación de transferencia
de fondos BanRep.
El usuario debe tener cuentas registradas.
137
Poscondiciones de éxito
Poscondiciones de fallo
Actores
primarios
secundarios
Disparador
Flujo de eventos
y
Selección de la operación de consultas.
1. El usuario selecciona la consulta deseada.
2. El sistema solicita los datos para efectuar la
consulta dependiendo de la consulta seleccionada.
3. El sistema efectúa la consulta.
4. El sistema despliega el resultado de la consulta.
3.1. El usuario puede efectuar consultas por fecha,
consultar los últimos 5 movimientos, y consultar
el saldo de sus cuentas.
2.1 Si el usuario selecciona consultar el saldo de las
cuentas, le son desplegados los saldos de todas
sus cuentas, si selecciona consultar últimos
movimientos le es solicitado el numero de la
cuenta y le son desplegados los últimos 5
movimientos, si selecciona consultar por fecha le
es solicitado el numero de las cuentas y las
fechas.
Sub-Variaciones
CASO DE USO # 8
Objetivo en contexto
Realizar Consulta - Visor
Permite a los auditores efectuar consultas sobre el la
base de datos de visor.
Transferencia de fondos BanRep - Visor
El sistema debe tener registradas todas las
operaciones efectuadas en la aplicación transferencia
de fondos BanRep, el usuario debe estar autenticado.
Alcance y nivel
Precondiciones
Poscondiciones de éxito
Poscondiciones de fallo
Actores
primarios
secundarios
Disparador
Flujo de eventos
El log es realizado y almacenado en la base de datos
del visor.
Las consultas no se pueden efectuar debido a un fallo
a nivel de comunicación.
Las consultas no se pueden efectuar debido a un fallo
en la base de datos de la aplicación.
Las consultas no se pueden efectuar debido al ingreso
erróneo de la información por parte del usuario.
Actor primario: Usuario del Sistema.
y
Se logran efectuar las consultas sobre la base de
datos del visor.
Las consultas no se pueden efectuar debido a un fallo
a nivel de comunicación.
Las consultas no se pueden efectuar debido a un fallo
en la base de datos del Visor.
Las consultas no se pueden efectuar debido al ingreso
erróneo de la información por parte del auditor.
Actor primario: Auditor.
Selección de la operación de consultar en el visor.
1. El sistema solicita el nombre de usuario y
contraseña al auditor.
138
2. El sistema autentica al auditor.
3. El usuario selecciona la consulta deseada.
4. El sistema solicita los datos para efectuar la
consulta dependiendo de la consulta seleccionada.
5. El sistema efectúa la consulta.
6. El sistema despliega el resultado de la consulta.
3.1. El usuario puede efectuar consultas por id de la
aplicación, id de la operación, y la cedula de un
cliente especifico.
4.1 Dependiendo del tipo de consulta y los datos
suministrados por el usuario el sistema muestra
el id de la aplicación, id de la operación, Cedula,
mensaje firmado, Firma y el timestamp de la
firma.
Sub-Variaciones
CASO DE USO # 9
Objetivo en contexto
Verificar Firma
Permite a los auditores verificar las firmas de las
operaciones.
Transferencia de fondos BanRep - Visor
El sistema debe tener registradas todas las
operaciones efectuadas en la aplicación transferencia
de fondos BanRep, el usuario debe estar autenticado.
Alcance y nivel
Precondiciones
Poscondiciones de éxito
Poscondiciones de fallo
Actores
secundarios
Disparador
primarios
Flujo de eventos
Sub-Variaciones
y
Se logra efectuar la verificación de las firmas
seleccionadas.
La verificación no se puede efectuar debido a un fallo
a nivel de comunicación.
La verificación no se puede efectuar debido a un fallo
en la base de datos del Visor.
Las consultas no se pueden efectuar debido al ingreso
erróneo de la información por parte del auditor.
Actor primario: Auditor.
Selección de la operación de verificar firma en el
visor.
1. El sistema solicita el nombre de usuario y
contraseña al auditor.
2. El sistema autentica al auditor.
3. El usuario selecciona la firma que desea verificar.
4. El sistema verifica la firma seleccionada.
5. El sistema despliega el resultado de la
verificación.
El sistema despliega la verificación de la firma, error
(si la firma no es valida), el mensaje firmado,
firmante, el serial que identifica el certificado del
firmante, y el emisor del certificado.
139