Download modelo de gestión de servicios pki basado en una arquitectura
Document related concepts
no text concepts found
Transcript
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