Ingeniero en Telemática

INSTITUTO POLITECNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA ENINGENIERÍA Y TECNOLOGÍAS AVANZADAS

U P I I T A

TRABAJO TERMINAL

"SISTEMA DE MONEDERO VIRTUAL PARA PAGOS ESCOLARES"

Que para obtener el título de

"Ingeniero en Telemática" PRESENTAN:

Martha Pamela Pastrana Alcalá Verenice Serrano Trujillo

ASESORES

M. en C. Susana Araceli Sánchez Nájera Ing. Francisco Antonio Polanco Montelongo

Lic. José Antonio Galván Pastrana

Junio del 2007

Sistema de Monedero Virtual para Pagos Escolares

I

CONTENIDO

Pág.Índice de figuras IIIÍndice de tablas VResumen VIAbstract VIPalabras clave VIObjetivos VII Objetivo general VII Objetivos particulares VIIIntroducción VIII1. Planteamiento del problema 12. Marco Teórico 2 2.1 Modelo Vista Controlador 2 2.1.1 Frameworks 2 2.1.2 Struts 4 2.1.2.1 Vista 5 2.1.2.2 Controlador 5 2.1.2.3 Modelo 5 2.2 Lenguaje de programación 6 2.3 Gestor de Bases de datos 7 2.4 Gestión de Transacciones 8 2.5 Seguridad de datos 9 2.5.1 Criptografía 9 2.5.1.1 Criptografía de clave simétrica 9 2.5.1.2 Criptografía asimétrica 10 2.5.2 Firma Digital 10 2.5.3 Métodos de autentificación 12 2.5.3.1 Kerberos 12 2.5.4 Certificados digitales 13 2.5.5 Algoritmos de cifrado 15 2.5.6 Apache Tomcat 16 2.5.7 Canal Seguro SSL 173. Desarrollo del Sistema 18 3.1 Descripción del Sistema 18 3.1.1 Distribución del sistema 18 3.2 Arquitectura general del sistema 19 3.3.Diseño 20 3.3.1 Escenario General 20 3.3.2 Diagrama de casos de uso 21 3.3.3 Diagrama de actividades 33 3.3.4 Modelo Entidad-Relación 36 3.3.5 Diagrama de clases 36 3.4 Desarrollo 39


II

3.4.1 Modelo Relacional 39 3.4.2 Implementación de Struts 40 3.4.3 Validación 42

3.4.4 Manejo de Transacciones 43 3.4.5 Configuración de SSL en Tomcat 45 3.4.6 Autenticación Kerberos v5 48 3.4.7 Implementación de JAAS 51 3.4.8 Implementación de Firma Digital 52 3.5 Emitir Recibo 55 4. Pruebas al sistema 58Conclusiones Trabajos Futuros Referencias


III

ÍNDICE DE FIGURAS Pág.1 Funcionamiento de Struts 42 Modelo de Cifrado simétrico 103 Criptografía de llave pública 104 Esquema de Firma Digital 115 Proceso de autenticación 136 Diagrama general del sistema 187 Arquitectura del sistema 198 Paquete general 209 Diagrama de Dependencias 2010 Caso de Uso Pagar 2111 Caso de Uso Realizar Cobro 2312 Caso de Uso Abono de Dinero 2513 Caso de Uso Agregar Registro 2714 Caso de Uso Eliminar Registro 2915 Caso de Uso Modificar Servicio 3116 Diagrama de Actividades, Abono de Dinero 3317 Diagrama de Actividades, Pago Directo 3418 Diagrama de Actividades, Modificar Registro 3519 Modelo Entidad-Relación 3620 Diagrama de Clases 3621 Clases ACTION y clases FORM 3722 Clases VO y clases DAO 3823 Modelo Relacional 3924 Archivo de configuración struts-config.xml (logeo) 4025 Ejecución de keytool 4526 Ingresar contraseña 4627 Datos del certificado 4628 Ubicación del keystore 4729 Certificado del Servidor 4730 Tomcat con https 4831 Recibo de Pago 5632 Página de Inicio 5833 Página de Inicio: Administrador 5934 Mensaje de error: Usuario no válido 5935 Error Sesión iniciada 6036 Menú Administrador 6037 Dar de alta un alumno 6138 Alumno registrado satisfactoriamente 6239 Eliminar un Alumno 6240 Alumno Eliminado 6341 Modificación de Alumnos 6342 Abono de dinero 64


IV

43 Saldo del Alumno 6544 Pago de Servicios 6545 Pago Realizado 6646 Saldo después del pago 66


V

ÍNDICE DE TABLAS Pág.1 Frameworks que implementan el MVC 22 Comparación entre lenguajes de programación orientada a objetos 63 Comparación entre los SGBD MySQL y PostGreSQL 84 Algoritmos de Cifrado 155 Código Procedimiento almacenado 406 Código de la clase LoginAAction.java 417 Clase validate 428 Clase Conexionad.java 439 Sentencias Java para el manejo de los comandos commit y rollback 4410 Archivo Server.xml 4511 Código del archivo krb5.conf 4912 Código del archivo kdc.conf 4913 Código para agregar un administrador 5014 Creación del archivo keytab 5015 Archivo de configuración jaas.conf 5116 Clase JaasAcn.java 5117 Clases JCA 5318 Clases JCE 5319 Código Firma Digital 5320 Claves pública y privada utilizadas para la firma digital 5521 Método de la clase DAO para obtener los datos del alumno 5622 Función imprimir 5723 Nombre y tipo de usuario 58


VI

RESUMEN RESUMEN El Sistema de Monedero Virtual para Pagos Escolares es un sistema de prepago, que permite a los alumnos realizar pagos dentro y fuera de la Unidad Profesional Interdisciplinaria en Ingeniería y Tecnologías Avanzadas (UPIITA). Constando este sistema de dos módulos: A distancia, para pagar servicios a través de la red de Internet y Directo, para pagos en la oficina. Para acceder al sistema se lleva acabo la autenticación de usuarios para evitar que personal no autorizado realice operaciones indebidas dentro del mismo. Debido a que se emplea un esquema de cliente-servidor se requiere que los datos que viajan del cliente al servidor no sean accedidos por personas no autorizadas, para ello se hace uso del protocolo SSL (Security Socket Layer). ABSTRACT The Virtual Wallet System for School Payments is a pre-payment system, that let pupils to do payments inside or outside Unidad Profesional Interdisciplinaria en Ingeniería y Tecnologías Avanzadas (UPIITA). This system has two parts: Far, for paying services through the Internet Web and Direct, for paying in the office. To access the system, it is important to have a user authentication to avoid that a person not authorized to do some operations in the system. This system uses the Security Socket Layer (SSL) that is a protocol that doesn’t let the data can be accessed by not authorized persons.

PALABRAS CLAVE Transacciones, prepago, pagos, autenticación, servicios, seguridad, certificados, firma digital, modelo, vista, controlador, hash, mensaje, Action, Form, struts.


VII

OBJETIVOS

OBJETIVO Desarrollar un sistema informático de monedero virtual para el pago de servicios escolares, para su uso a través de Internet o dentro de la institución educativa, UPIITA. OBJETIVOS PARTICULARES

1. Crear estados de cuenta seguros en los que se observen los movimientos realizados por cada alumno.

2. Implementar las transacciones que garanticen las normas ACID.

3. Realizar la autenticación de usuarios, para garantizar que sólo los usuarios válidos

ingresen al sistema.


VIII

INTRODUCCIÓN

En la actualidad los sistemas de prepago forman una alternativa bastante concurrida por las personas, debido a que pueden solventar gastos sin necesidad de utilizar dinero en efectivo para pagar algún servicio o producto. No obstante, este tipo de tecnologías requiere de una tarjeta o dispositivo para ingresar al sistema y poder pagar dichos servicios. El Sistema de Monedero Virtual para Pagos Escolares tiene la finalidad de implementar un proceso de prepago para los alumnos que asisten a la Unidad Profesional Interdisciplinaria en Ingeniería y Tecnologías Avanzadas, para realizar el pago de servicios desde cualquier lugar sin tener que trasladarse a la institución para efectuarlos. Los usuarios no requieren del manejo de credenciales o tarjetas para hacer uso del sistema, ya que solo emplea claves de acceso y un número de identificación personal. Está dirigido especialmente a los alumnos de la UPIITA, sin embargo, es una alternativa para cualquier institución educativa o empresarial debido a que esta estructurado de manera que puede adecuarse a sus necesidades de manera sencilla. Este sistema tiene ventajas en cuanto a que emplea módulos de seguridad que garantizan que los datos no son modificados en su transmisión y permite la autenticación de usuarios para evitar que personas no registradas hagan uso indebido del mismo. Garantiza que al manejarlo las operaciones deseadas se realizaran en su totalidad, y en caso de falla los datos no sufren cambios si se interrumpe la transacción. El documento consta de 4 capítulos, los cuales abordan la problemática que se pretende resolver, así como la solución que se propone y el diseño del sistema, haciendo un análisis de cada una de las herramientas que serán utilizadas a lo largo del desarrollo e implementación de sistema. En el capítulo 1 se realiza el planteamiento del problema para llevar acabo pagos dentro de la institución cuando se solicita un servicio, además se hace una descripción de cómo se lleva a cabo este proceso en la actualidad. El capítulo 2 contiene la investigación de las herramientas existentes que serán utilizadas durante el desarrollo del sistema, resaltando sus principales ventajas y características.

El capítulo 3 contiene el análisis de los requerimientos del sistema y la función que desempeñan las herramientas, así como también el diseño y desarrollo del sistema. En el capitulo 4 se muestran las pruebas realizadas al sistema explicando los resultados que se obtienen en la ejecución de los distintos escenarios.


1

1. PLANTEAMIENTO DEL PROBLEMA

Dentro de la institución educativa (UPIITA), se ofrecen distintos servicios, como lo son la impresión, fotocopiado, pago de trámites: constancias, boletas globales, adelanto de asignaturas, bajas cambio de carrera, turno y grupo, recursamientos, exámenes a título de suficiencia (ETS); multas de biblioteca, cursos, resello de credencial de biblioteca, y toma de protesta, entre otros. Estos servicios requieren de un pago previo una vez que son solicitados, sin embargo, para realizar dicho pago la mayoría de las ocasiones es necesario acudir a la caja de la escuela. La cajera proporciona una papeleta que se debe llenar con los datos del interesado, indicando el nombre del servicio que se quiere pagar, cantidad de servicios que se solicitan, monto o precio de los mismos y total a pagar; posteriormente, se firma la papeleta y se realiza el cobro; sin embargo, es indispensable llevar la cantidad exacta que se va a pagar, de otro modo no se realiza el cobro. Después el comprobante de pago debe ser llevado a la oficina que presta el servicio. Esto implica disponibilidad de tiempo con el que a veces no se cuenta. Otra de las desventajas que se presentan en los procesos de pago es que deben ser en efectivo.


2

2. 2.

MARCO TEORICO 2.1 Modelo Vista Controlador El Modelo Vista Controlador (MVC), fue propuesto por Trygve Reenskavg en 1979[1][2], y consiste en una arquitectura que separa las aplicaciones en tres capas, permitiendo realizar modificaciones de forma fácil sin tener que afectar a otra capa, de esta forma se puede reutilizar el código. Las capas de las que se compone son:

- Modelo: es la representación específica del dominio de la información sobre la cual funciona la aplicación, es decir, el que contiene los datos a manipular añadiendo un significado a éstos, es independiente de su representación.

- Vista: es aquella que determina la forma en la que se presentará la información o datos al usuario. Se pueden definir tantas vistas como sea necesario. Cada vista tiene asociado un componente controlador.

- Controlador: es aquel que hace posible la comunicación de las capas anteriores. Haciendo cambios al modelo y muy probablemente a las vistas. Los eventos son traducidos a solicitudes de servicio (“service requests”) para el modelo o la vista.[3],

2.1.1 Frameworks Un framework o marco de trabajo, es una estructura de software con componentes personalizables e intercambiables para el desarrollo de una aplicación, con esto se busca acelerar el proceso de desarrollo, así como reutilizar el código ya existente. El uso de frameworks modela las relaciones generales de las entidades del dominio. Los frameworks más utilizados en el patrón MVC se describen en la Tabla 1. Framework Descripción Apache Cocoon Está construido en los conceptos de desarrollo Web, enfocado en la

publicación de XML y XSLT, y construido usando programación java.

Atlas Es un framework de Microsoft que se encuentra integrado en Visual Studio 2005 y pertenece a la plataforma ASP.NET. Se basa en el desarrollo de aplicaciones Web dinámicas. Para lograr una flexibilidad en la creación de las aplicaciones se incluye una poderosa herramienta de desarrollo: el Visual Web Developer y SQL Server Express como una herramienta de base de datos.


3

Framework Descripción Catalyst Se usa para aplicaciones Web open-source escrito en Perl, promueve

la reutilización de los módulos de Perl.Catalyst; soporta la arquitectura MVC:

• La parte de Modelo (Model) es manejada por medio de DBIx:Class, Plucene, Net::LDAP u otras clases modelo.

• La parte de Vista (View) es usualmente manejada por Template Toolkit, Mason o HTML::Template.

• Control (Controller) la funcionalidad usualmente se puede conseguir con plugins como:

Catalyst::Plugin::FormValidator, Catalyst::Plugin::Prototype Dojo toolkit Contiene APIs y widgets (controles) para soportar el desarrollo de

aplicaciones Web. Incluye sistema de empaquetado inteligente, los efectos de UI, drag and drop APIs, widget APIs, abstracción de eventos, almacenamiento de APIs en el cliente, e interacción de APIs con AJAX. No es completamente soportado en el cliente. Proporciona una gama más amplia de opciones en una sola biblioteca y hace un trabajo muy bueno que apoya los nuevos y viejos Browsers.

Gstreamer Es un framework multimedia libre para sistemas UNIX (GNU/Linux, BSD, etc.). Inicialmente fue adoptado por el proyecto GNOME, luego siguió su evolución y cada vez más aplicaciones lo utilizan. Se prevé que se convierta también en el framework de KDE.

Struts Es una herramienta de soporte para el desarrollo de aplicaciones Web bajo el patrón MVC y la plataforma J2EE (Java 2, Enterprise Edition). Es una herramienta altamente disponible. Implementa un solo controlador (ActionServlet) que evalúa las peticiones del usuario mediante un archivo configurable (struts-config.xml). En cuanto al MVC, el módulo de modelos corresponde a la lógica del negocio con el cual se comunica la aplicación Web. Usualmente el modelo comprende accesos a Bases de Datos o sistemas que funcionan independientemente de la aplicación Web. Los componentes de control son los encargados de coordinar las actividades de la aplicación, que van desde la recepción de datos del usuario, las verificaciones de forma y la selección de un componente del modelo a ser llamado. Por su parte los componentes del modelo envían al control sus eventuales resultados o errores de manera de poder continuar con otros pasos de la aplicación.

Prototype Es un framework basado en JavaScript que se orienta al desarrollo sencillo y dinámico de aplicaciones Web. Es una herramienta que implementa las técnicas AJAX y su potencial es aprovechado al máximo cuando se desarrolla con Ruby On Rails, fue desarrollado por Sam Stephenson. Funciona perfectamente para páginas que son altamente interactivas.


4

Framework Framework Descripción Ruby on Rails También conocido como RoR o Rails es un framework de

aplicaciones Web de código abierto escrito en el lenguaje de programación Ruby, siguiendo el paradigma de la arquitectura MVC. Trata de combinar la simplicidad con la posibilidad de desarrollar aplicaciones del mundo real escribiendo menos código que con otros frameworks y con un mínimo de configuración. El lenguaje de programación Ruby permite la metaprogramación, de la cual Rails hace uso, lo que resulta en una sintaxis que muchos de sus usuarios encuentran muy legible. Rails se distribuye a través de RubyGems, que es el formato oficial de paquete y canal de distribución de librerías y aplicaciones Ruby.

Spring Es más que un framework MVC y contiene módulos para encapsular el código de acceso a datos y transacciones permitiendo la integración de otros frameworks de persistencia como Toplink, Hibernate, JDO, y iBATIS SQL Maps.

Tabla 1. Frameworks que implementan el MVC 2.1.2 Struts Considerando la arquitectura MVC, las aplicaciones Struts tienen tres componentes principales: un Servlet controlador, que esta proporcionado por el propio Struts, JavaServer Pages(JSP) y la lógica de negocio. El navegador genera una solicitud que es atendida por el Controlador (un servlet especializado). El mismo se encarga de analizar la solicitud, seguir la configuración que se ha programado en el struts-config.xml y llamar al Action correspondiente pasándole los parámetros enviados. El Action instancia y/o utiliza los objetos de negocio para concretar la tarea. Según el resultado que retorne el Action, el controlador derivará la generación de interfaz a una o más JSP’s, las cuales podrán consultar los objetos del modelo para mostrar la información de los mismos. La figura 1 muestra el funcionamiento de Struts.


5

Figura 1. Funcionamiento de Struts 2.1.2.1 Vista La Vista se encuentra conformada por un conjunto de páginas JSP. Struts proveve soporte para construir aplicaciones multi-idioma, interacción con formularios y otras utilidades mediante la utilización de Tags especiales (TagLibraries). 2.1.2.2 Contralador

El Controlador comprende la funcionalidad involucrada desde que un usuario genera un pedido HTTP(clic en un link, envío de un formulario, etc.) hasta que se genera la interfaz de respuesta. Entre estas dos acciones, llamará a los objetos de negocio del Modelo para que resuelvan funcionalidad propia de la lógica de negocio y según el resultado de la misma ejecutará la JSP que deba generar la interfaz resultante. Struts incluye un servlet que a partir de la configuración de struts-config.xml recibe las solicitudes del usuario, llama al Action que corresponda y, según lo que éste retorne, ejecuta una JSP. La clase Action El objetivo de una clase Action es procesar una solicitud, mediante su método perform(), y devolver un objeto ActionForward que identifica donde se reenvía el control(por ejemplo una JSP) para proporcionar la respuesta apropiada. El archivo struts-config.xml Dentro del archivo struts-config.xml, hay dos elementos importantes que son usados para describir las acciones:

• <form-beans>. Esta sección contiene las definiciones de beans. Se usa un elemento <form-bean> por cada bean de formulario, tiene los siguientes atributos:

o name: un identificador único para este bean, que será usado para referenciarlo en los correspondientes mapeos de acciones.

o type: el nombre totalmente cualificado de la clase Java del bean de formulario.

• <action-mappings>. Esta sección contiene las definiciones de acciones. Se utiliza un elemento <action> por cada una de las acciones que se quieran definir. Cada elemento action requiere que se definan los siguientes atributos:

o path: el path a la clase Action en relación al contexto de la aplicación. o type: el nombre totalmente cualificado de la clase Java de nuestra clase

Action. o name: el nombre del elemento <form-bean> para usar con esta action.

2.1.2.3 Modelo El modelo contiene todos los objetos donde se implementa la lógica de negocio y donde se debe soportar todos los requisitos funcionales del sistema sin mezclarlo con partes correspondientes al Controlador.


6

Action Form Las comprobaciones, la gestión de errores, el volver a presentar el mismo form al usuario con los valores que puso y los mensajes de error, etcétera, están soportadas por Struts, a fines de hacer el trabajo mas fácil. Todo el trabajo de comprobaciones y generación de mensajes de error se implementa en los ActionForm y lo referente a la generación de interfaz en las JSP’s.[4]. 2.2 Lenguaje de programación Los lenguajes de programación son una secuencia de instrucciones que permiten a un ordenador procesar una información conocida como datos de entrada (input) para producir información de salida (ouput). Entre ellos se encuentran Visual Basic.Net, PHP, C++, Java, etc. Una computadora funciona bajo control de un programa el cual debe estar almacenado en la unidad de memoria, tales como el disco duro. La tabla 2 muestra una comparativa de algunos lenguajes de programación considerando las características mostradas en la misma. [5] Característica C++ Visual Basic

.Net Java PHP

Complejidad Alta Baja Regular Regular Robustez No Sí Sí No Seguridad No Sí Sí Sí Interpretado No Sí Sí Sí Dinamicidad No No Sí No Portabilidad No Sí Sí Sí Flexibilidad Sí Sí No Sí Herencia múltiple Sí No No No Polimorfismo Sí Sí Sí Sí Threads No Sí Sí No Garbage Collector (reciclador de memoria dinámica)

No No Sí Sí

Excepciones Algunas Sí Sí Sí


7

Característica Característica C++ Visual Basic

.Net Java PHP

Ejecución -Rápida -únicamente en la plataforma en la que se generó

Depende del Windows donde sea ejecutado

- de 10 a 30 veces más lenta que C++ -en cualquier maquina que tenga el sistema de ejecución

Muy rápida para LINUX, se puede adecuar con otras plataformas de UNIX o Windows

Es multiplataforma No No Sí Sí Arquitectura de desarrollo orientada a Internet

No Sí Sí Sí

Tabla 2. Comparación entre lenguajes de programación orientada a objetos 2.3 Gestor de Bases de Datos El sistema gestor de bases de datos (SGBD) consiste en una colección de datos interrelacionados y un conjunto de programas para acceder a dichos datos, esta dedicado a servir de interfaz entre la Base de Datos (BD), el usuario y las aplicaciones que la utilizan. La gestión de los datos implica tanto la definición de las estructuras para almacenar la información como la provisión de mecanismos para la manipulación de la información. Los SGBD proporcionan un lenguaje de definición de datos para especificar el esquema de las BD y un lenguaje de manipulación de los datos para expresar las consultas y las modificaciones de la BD. En la práctica, los lenguajes de definición y manipulación de datos no son dos lenguajes diferentes; en cambio, simplemente forman parte de un único lenguaje de BD.

El propósito general de los SGBD es manejar de manera clara, sencilla y ordenada un conjunto de información. [6]

Ventajas del uso de SGBD:

• Facilidad de manejo de grandes volúmenes de información. • Gran velocidad en muy poco tiempo. • Independencia del tratamiento de información. • Seguridad de la información (acceso a usuarios autorizados), protección de

información, de modificaciones, inclusiones, consulta. • No hay duplicidad de información, comprobación de información en el

momento de introducir la misma. • Integridad referencial el terminar los registros.

Algunos SGBD son: SQLServer, Oracle, MySQL y PostGreSQL. En la tabla 3 se muestra una comparación entre los SGBD MySQL y PostGreSQL.


8

Característica MySQL PostGreSQL Soporta transacciones Si Si Soporta procedimientos almacenados

Si Si

Soporta subconsultas Si Si Soporta Triggers Si Si Tiempo de respuesta Rápido Rápido Consumo de recursos Mínimo Regular Soporte aplicaciones Java Si Si Portabilidad Gran portabilidad

entre sistemas Regular

Versión estable MySQL 4.0 Postgre 7.0 Seguridad de datos Buen nivel Regular Integridad referencial Si Si Multiplataforma Si.

GNU/Linux, Solaris, SCO OpenServe, diferentes versiones de Windows

Si Windows, Solaris, UNIX

Tabla 3. Comparación entre los SGBD MySQL y PostGreSQL 2.4 Gestión de Transacciones Varias operaciones sobre la BD forman una única unidad lógica de trabajo. Un ejemplo es la transferencia de fondos, en la que se realiza un cargo en una cuenta y un abono en otra cuenta. Es fundamental que se realicen las dos operaciones (el cargo y el abono), o bien que no se lleve acabo ninguna de las dos. Este requisito de todo o nada es denominado atomicidad. Además, resulta esencial que la ejecución de la transferencia de fondos preserve la consistencia de la BD. Es decir, el valor de la suma A + B se debe preservar. Este requisito de corrección se denomina consistencia. Finalmente, tras la ejecución correcta de la transferencia de fondos, los nuevos valores de las cuentas A y B deben persistir, a pesar de la posibilidad de fallo del sistema. Este requisito de persistencia se denomina durabilidad. Una transacción es un conjunto de operaciones que lleva acabo una única operación lógica en una aplicación de BD. Cada transacción es una unidad de atomicidad y consistencia. Por tanto se exige que las transacciones no violen ninguna restricción de consistencia de la BD. Es responsabilidad del sistema de BD garantizar la atomicidad y durabilidad, a través del componente de gestión de BD, así como también se debe de realizar la recuperación de fallos, detectando los errores ocurridos y restaurando la BD en el estado anterior al fallo. Finalmente cuando varias transacciones actualizan la BD de manera concurrente, puede ocurrir que no se preserve la consistencia de los datos, por lo cual es recomendable tener un gestor de control de concurrencia. [7]


9

2.5 Seguridad de datos No existe una definición puntual de Seguridad de Datos, ya que se puede contemplar desde la seguridad física del hardware, hasta la protección de la información que contiene tal hardware o la que viaja por las redes que lo comunican al exterior. Sin embargo una definición operacional es: “Un sistema es seguro si podemos contar con que su hardware y software se comportan como se espera de ellos” Los aspectos fundamentales que definen la seguridad de datos son:

-Autenticación: Proporcionar los medios necesarios para avalar que un usuario es quien dice ser. -Integridad: Además de la autenticación de usuarios, proporcionar la validez de los datos transmitidos, es decir, el mensaje debe llegar a su destino sin sufrir alteraciones. -Confidencialidad: Proporcionar un canal seguro donde viajará la información para protegerla y mantener en secreto la identidad del emisor y receptor. -Control de acceso: Sólo los usuarios autorizados y debidamente identificados pueden obtener permiso de acceso a los recursos del sistema.

2.5.1 Criptografía La criptografía se refiere al estudio de técnicas matemáticas relacionadas a los aspectos de seguridad de la información. En concreto, su función es transformar un mensaje claro mediante un algoritmo y llaves, en un texto no entendible, a excepción del receptor quien podrá realizar la operación inversa del algoritmo de cifrado y obtener el mensaje en claro. 2.5.1.1 Criptografía de clave simétrica La criptografía de clave simétrica, secreta o privada, se basa en el uso de una sola llave para cifrar y descifrar, es decir, tanto emisor como receptor necesitan compartir una llave en común. Es importante observar que la seguridad del cifrado simétrico depende de la privacidad de la clave y no de la privacidad del algoritmo, es decir, no es necesario que el algoritmo sea secreto lo que hay que mantener en secreto es la clave. La figura 2 muestra el funcionamiento del cifrado simétrico.


10

Figura 2. Modelo de cifrado simétrico 2.5.1.2 Criptografía de clave asimétrica.

Para la criptografía de clave asimétrica o pública cada usuario del sistema criptográfico debe poseer una pareja de claves, una clave privada que será custodiada por su propietario y no se dará a conocer a ningún otro; y una clave pública, la cual será conocida por todos los usuarios.

Esta pareja de claves es complementaria: lo que cifra una clave sólo lo puede descifrar la otra y viceversa. Estas claves se obtienen mediante métodos matemáticos complicados de forma que es imposible conocer una clave a partir de la otra.

La figura 3 muestra el funcionamiento de la criptografía de llave pública. [8]

Figura 3. Criptografía de llave pública.

2.5.2 Firma digital Es una cadena de datos creada a partir de un mensaje o parte de él, de forma que no se sea sencillo negar la fuente donde fue generada (repudio), así mismo el receptor puede asegurar que el emisor es realmente quien dice ser llevando acabo la autenticación.


11

Además, las firmas digitales garantizan la integridad de los datos, evitando que sufran alteraciones durante su transmisión. Las firmas digitales se construyen utilizando criptografía de clave pública, la cual utiliza dos claves, una privada y otra pública. La primera se mantiene en secreto y la segunda se divulga libremente. Para firmar es necesario utilizar la clave privada y para verificar la firma se utiliza la clave pública. Para que una firma digital producida sea válida debe cumplir:

• Vigencia. Haber sido creada durante el período de vigencia del certificado digital válido del firmante.

• Verificación. Ser debidamente verificada por la referencia a los datos de verificación de firma digital indicados en dicho certificado según el procedimiento de verificación correspondiente.

• Emisión. Que dicho certificado haya sido emitido o reconocido por un certificador licenciado.

La figura 4 muestra un esquema de firma digital, el cual cuenta con dos partes, la primera se denomina proceso de firma y la segunda parte proceso de verificación de la firma. [9]

Figura 4. Esquema de Firma Digital

El primer paso para firmar el documento es realizar una función resumen también conocida como función hash, la cual se encarga de recibir el mensaje de longitud variable y regresar como salida un resumen de longitud fija para ser cifrado a través de la una clave privada. De esta manera se obtiene la firma digital.


12

El paquete que se envía contiene el documento original y la firma digital. Cuando este paquete llega al receptor, se toma al documento y nuevamente se le aplica una función hash para obtener su resumen para compararlo con la firma descifrada mediante la clave publica del receptor, si ambos resultados son iguales la firma realmente es valida, sino, quiere decir que hubo alteraciones en los datos durante su transmisión. 2.5.3 Métodos de autenticación El objetivo de la autenticación es permitirle a una persona autorizada el acceso a un recurso, con la previa verificación de que cumple con las condiciones exigidas. Comúnmente los métodos de autenticación se clasifican de acuerdo con su relación con el usuario en:

• Datos conocidos por el usuario: dentro de esta categoría están las contraseñas y los NIP (Números de Identificación Personal). El problema de este método es la longitud de la contraseña.

• Métodos biométricos: son los métodos que se basan en características físicas del usuario como escaneo de retina, reconocimiento de huella digital, de iris, cara, entre otros, o en el comportamiento, como análisis de firma, reconocimiento de voz, etc.

• Dispositivos: en esta clasificación se encuentran las tarjetas de chip o banda magnética, módulos de seguridad, etc. La principal desventaja es que no se debe extraviar el dispositivo.

Algunos de los mecanismos de autenticación son: Kerberos, RADIUS, NetSP, SPX. 2.5.3.1 Kerberos Kerberos es un protocolo de autenticación de redes de ordenador que permite a dos computadores en una red insegura demostrar su identidad mutuamente de manera segura. Kerberos evita ataques de escucha (eavesdropping), ataques de Replay, y garantiza la integridad de datos. Sus diseñadores se concentraron primeramente en un modelo de cliente-servidor, y brinda autenticación mutua: tanto cliente como servidor verifican la identidad uno del otro. Está basado en criptografía de clave simétrica, y necesita de un tercero confiable (KDC o Key Distribution Center) el cual consiste de dos partes lógicas: [10]

• Un servidor de autenticación (AS) y • Un servidor de Otorgamiento de Tickets (TGS)

Trabaja sobre la base de “tickets” los cuales sirven para probar la identidad de los usuarios. El sistema mantiene una base de datos de claves secretas, las cuales corresponden cada una a una entidad en la red.


13

Para que los passwords no viajen por la red se utilizan tickets para validar el acceso a los servicios. Estos tickets deben estar en posesión del usuario y enviarse a los servidores para conseguir el acceso. Un ticket es información encriptada con un passwords del sistema que permite el acceso al usuario que lo posee. Siempre tienen una fecha de caducidad para que no puedan ser aprovechados por los espías de la red. Tampoco se guardan passwords ni tickets en las máquinas de los usuarios para evitar a los Hackers que tienen accesos a estas máquinas. El proceso de autenticación se divide en dos fases y 6 mensajes. La figura 5 muestra dichas fases.

Figura 5: Proceso de autenticación

Las fases son las siguientes: 1. Autenticación de usuario. Mensajes 1 y 2. 2. Autenticación de servicio. Mensajes 3, 4, 5 y 6. Al conectarse se debe realizar la autenticación del usuario al sistema Kerberos y después se pueden hacer tantos de servicios como se necesiten conectar, pero sin necesidad de repetir la de usuario. 2.5.4 Certificados digitales

Un certificado de clave pública es un paquete de información utilizado para pasar de forma segura la identidad de un usuario a un servidor o un servicio; es un punto de unión entre la clave pública de una entidad y uno o más atributos referidos a su identidad. El certificado garantiza que la clave pública pertenece a la entidad identificada y que la entidad posee la correspondiente clave privada. Los certificados digitales proporcionan un mecanismo criptográfico para implementar la autentificación; también proporcionan un mecanismo seguro y escalable para distribuir claves públicas en comunidades grandes. Por lo que no hay algoritmos que realicen certificados digitales, si no que dichos certificados deben tener un formato, es decir, incluir determinada información.

Cliente AS

Servidor TGS

1

2

3

4 6 5


14

El formato de certificados X.509 es un estándar del ITU-T (International Telecommunication Union-Telecommunication Standarization Sector) y el ISO/IEC (International Standards Organization / International Electrotechnical Commission).

Los elementos del formato de un certificado X.509 v3 son:

• Versión. El campo de versión contiene el número de versión del certificado codificado. 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 (Certification Authority o Autoridad Certifícante) debe tener un número de serie único.

• Identificador del algoritmo de firmado. Este campo identifica el algoritmo empleado para firmar el certificado.

• 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.

• 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.

Otra forma de clasificar los elementos del certificado X.509, es la siguiente:

• Subject, contiene los datos que identifican al titular. Estos datos están expresados en notación DN (Distinguished Name), donde un DN se compone a su vez de diversos campos, los más frecuentes son: CN (Common Name), OU (Organizational Unit), O (Organization) y C (Country). También contiene datos asociados al propio certificado digital, como la versión del certificado, su identificador (serialNumber), la CA firmante (issuer), el tiempo de validez (validity), etc. La versión X.509.v3 también permite utilizar campos opcionales (nombres alternativos, usos permitidos para la clave, ubicación de la CRL (Certification Revocation Lists o Listas de anulación de certificados) y de la CA, etc.

• La clave pública, que expresada en notación ASN.1, consta de dos campos, en primer lugar, el que muestra el algoritmo utilizado para crear la clave, y en segundo lugar, la clave pública.


15

• La CA, añade la secuencia de campos que identifican la firma de los campos previos. Esta secuencia contiene tres atributos, el algoritmo de firma utilizado, el hash de la firma y la propia firma digital. [11]

2.5.5 Algoritmos de Cifrado Un algoritmo de cifrado es aquel que, con base en una clave o llave, hace transformaciones al mensaje en texto claro, para que este sea ininteligible para cualquier persona que lo obtenga, excepto para el poseedor de la clave de descifrado. En la tabla 4 se observa una descripción breve de algunos algoritmos de cifrado. [12]

Algoritmo Descripción

AES

Es conocido como Rijndael, es un esquema de cifrado por bloque adoptado como un estándar de encriptación por el gobierno de los Estados Unidos. Tiene un tamaño de bloque fijo de 128 bits y tamaños de llave de 128, 192 ó 256 bits. Opera en un arreglo de 4×4 bytes, llamado state.

RSA

Es un sistema criptográfico con clave pública, por lo tanto se considera como algoritmo asimétrico cifrador de bloques, que utiliza una clave pública, la cual se distribuye en forma autenticada preferentemente, y otra privada, la cual es guardada en secreto por su propietario. Los mensajes enviados a través de este algoritmo se representan mediante números el funcionamiento se basa en el producto de dos números primos grandes (mayores que 10100) elegidos al azar para conformar la clave de descifrado.

DES Este algoritmo fue escogido como FIPS en los Estados Unidos en 1976. Su longitud de clave de 56 bits. Es muy inseguro. Ha sido sustituido por AES.

IDEA

Es un cifrado de bloque diseñado por Xuejia Lai y James L. Massey de ETH-Zurich y descrito por primera vez en 1991. Opera con bloques de 64 bits usando una clave de 128 bits y consiste en ocho transformaciones idénticas y una transformación de salida (media ronda). El proceso para encriptar y desencriptar es similar. Utiliza tres operaciones en su proceso con las cuales logra la confusión, se realizan con grupos de 16 bits.

DSA

Algoritmo propuesto por el Instituto Nacional de Normas y Tecnología de los Estados Unidos para firmas digitales. DSA se hizo público el 30 de agosto de 1991, este algoritmo sólo sirve para firmar y no para cifrar información. Una desventaja de este algoritmo es que requiere mucho más tiempo de cómputo que RSA.

TEA

Fue diseñado por David Wheeler y Roger Needham del Cambridge Computer Laboratory, y presentado por vez primera en 1994 en el Fast Software Encryption Workshop. Opera sobre bloques de 64 bits y usa una clave de 128 bits. Contiene una estructura de red de Feistel aconsejada en 64 rondas, implementadas en parejas denominadas ciclos. Posee una generación de claves mezclando todo el contenido de la clave de la misma manera para cada ciclo. Es susceptible a ataques de clave relacionada que requieren 223 textos planos escogidos para un par de claves relacionadas, con una complejidad cronológica de 232.


16

Algoritmo Descripción

ECDSA

Es una modificación del algoritmo DSA que emplea operaciones sobre puntos de curvas elípticas en lugar de las exponenciaciones que usa DSA. La principal ventaja de este esquema es que requiere números de tamaños menores. Existen dos tipos de curvas dependiendo del campo finito en el que se definan que pueden ser GF(P) o GF(2m).

MD5 Es un algoritmo de reducción criptográfico de 128 bits ampliamente usado. El código MD5 fue diseñado por Ronald Rivest en 1991. La codificación de 128 bits es representada típicamente como un número de 32 dígitos hexadecimal.

ARC4

Es el sistema de cifrado de flujo Stream Chipre. Genera un flujo pseudoaleatorio de bits (un keystream) que, para encriptación, se combina con el texto plano usando la función XOR. La fase de descifrar el mensaje se realiza del mismo modo. Tiene un estado interno secreto que consiste en:

1. Una permutación de todas las posibles con 256 bytes .

2. Dos índices-apuntadores de 8 bits

Sha1

Es un sistema de funciones hash criptográficas relacionadas de la Agencia de Seguridad Nacional de los Estados Unidos y publicadas por el National Institute of Standards and Technology (NIST). Producen una salida resumen de 160 bits de un mensaje que puede tener un tamaño máximo de 264 bits.

Tabla 4. Algoritmos de cifrado

2.5.6 Apache Tomcat Tomcat es un servidor Web con soporte de servlets y JSP, también es llamado Jakarta Tomcat o Apache Tomcat. Apache Tomcat se desarrolla en un ambiente abierto y participante y se lanza debajo de la licencia del software de Apache. En sus inicios existió la percepción de que el uso de Tomcat de forma autónoma era sólo recomendable para entornos de desarrollo y entornos con requisitos mínimos de velocidad y gestión de transacciones. Hoy en día ya no existe esa percepción y Tomcat es usado como servidor Web autónomo en entornos con alto nivel de tráfico y alta disponibilidad. Debido a que el proyecto requiere de la una interfaz Web, se requiere de este tipo de servidor para interpretar el código. [13] La jerarquía de directorios de instalación de Tomcat incluye:

bin - arranque, cierre, y otros scripts y ejecutables. common - clases comunes que pueden utilizar Catalina y las aplicaciones web. conf - ficheros XML y los correspondientes DTD para la configuración de

Tomcat.


17

logs - logs de Catalina y de las aplicaciones. server - clases utilizadas solamente por Catalina. shared - clases compartidas por todas las aplicaciones web. webapps - directorio que contiene las aplicaciones web. work - almacenamiento temporal de ficheros y directorios.

2.5.7 Canal Seguro SSL SSL (Secure Sockets Layer) fue diseñado y propuesto en 1994 por Netscape Communications Corporation junto con su primera versión del Navigator. En su estado actual, proporciona cifrado de datos, autenticación de servidores, integridad de mensajes y, opcionalmente, autenticación de cliente para conexiones TCP/IP. No se necesita realizar ninguna acción especial para invocar el protocolo SSL, basta con seguir un enlace o abrir una página cuya dirección empieza por https://. El navegador se encarga del resto. Eso sí, asegúrese de que tiene SSL habilitado en su navegador. [14] SSL aporta las siguientes características:

• Confidencialidad Mediante el uso de la Encriptación se garantiza que los datos enviados y recibidos no podrán ser interpretados por ninguna otra persona que no sea ni el emisor ni el receptor.

• Integridad Se garantiza que los datos recibidos son exactamente iguales a los

datos enviados, pero no se impide que al receptor la posibilidad de modificar estos datos una vez recibidos.

• Autentificación El emisor se autentifica utilizando un Certificado Digital

emitido por una empresa llamada Autoridad Certificadora, este documento es totalmente infalsificable y garantiza que el Vendedor es quien dice ser.

Solicitud de SSL: Antes de que se establezca SSL, se debe hacer una solicitud. Típicamente esto implica que un cliente realiza la solicitud de un URL a un servidor que soporte SSL. SSL acepta solicitudes por un puerto diferente al utilizado normalmente para ese servicio se hace uso del puerto 8443. Una vez se ha hecho la solicitud, el cliente y el servidor empiezan a negociar la conexión SSL, es decir, hacen el SSL Handshake, durante el se cumplen varios propósitos. Se hace autenticación del servidor y opcionalmente del cliente, se determina que algoritmos de criptografía serán utilizados y se genera una llave secreta para ser utilizada durante el intercambio de mensajes subsiguientes y la comunicación SSL.


18

3. 3.

DESARROLLO DEL SISTEMA 3.1 Descripción del sistema El sistema tiene dos módulos, descritos a continuación.

-A distancia: A través de una interfaz Web, de manera que el alumno puede realizar los pagos correspondientes sin necesidad de trasladarse a la institución educativa. -Directo: Directamente en la oficina en la cual se requiera hacer un pago.

Figura 6. Diagrama general del sistema.

Ambos módulos tienen una interfaz gráfica para que el usuario interactúe con el sistema de forma sencilla permitiendo que se lleve a cabo el pago de los servicios. Así mismo, dentro de una base de datos se encuentra contenida la información necesaria para cada uno de los módulos llevando un registro de los alumnos, del personal encargado, de los servicios que se ofrecen así como los movimientos realizados. 3.1.1 Distribución del sistema De acuerdo a la figura 6 se tiene la siguiente distribución:

• C1: Finanzas. • C2: usuario. • C3: terminales de pago (control escolar, biblioteca o cómputo).

C1 (Finanzas): Es la parte medular del proyecto ya que es aquí donde se tiene el servidor, la base de datos y donde se lleva a cabo toda la administración de alumnos y administración de servicios.

Internet

Servidor

BD

Alumno

Terminales de

pago

C3

C1

C3

C2


19

C2 (Usuario): Consiste en una aplicación que realiza pagos por medio de la red de Internet, por lo tanto es necesario implementar algoritmos y protocolos que ayuden a mantener la seguridad en el sistema, protegiéndolo de ataques externos, que puedan alterar la información e incluso la suplantación de un usuario. C3 (Terminales de pago): En cada oficina donde se requiere realizar el pago de algún servicio (por ejemplo: cómputo, biblioteca, fotocopiado etc.) existe una Terminal. 3.2 Arquitectura del sistema La figura 7 muestra la arquitectura del sistema.

SSLALUMNO

AUTENTICACIÓN FINANZAS BD

k

SSL

TERMINAL DE PAGO

SERVIDOR

Figura 7. Arquitectura del sistema

Alumno: Puede realizar un pago, así como consultar los servicios que se pueden pagar Terminal de pago: Puede realizar consultas a la base de datos y registrar pagos realizados por los alumnos. Para establecer un canal seguro entre el browser y un servidor Web se utiliza el protocolo SSL (Secure Sockets Layer). Servidor: Contiene los elementos Finanzas y Autanticación.

Finanzas: Aquí se lleva a cabo la administración de alumnos y de servicios en la BD. También se generan los estados de cuenta para los alumnos y un estado de cuenta por departamento.

Autenticación: Se encuentra almacenada la BD de Kerberos V5 con los

nombres de usuarios del sistema y sus contraseñas. Aquí se lleva cabo toda la administración de dicha BD.


20

3.3 Diseño 3.3.1 Escenario General La interfaz gráfica con la que interactúa el usuario proporciona alternativas que ocasionan cambios significativos en la base de datos, dichas opciones se muestran en los escenarios descritos en los diagramas de casos de uso y en los diagramas de secuencia. Las figuras 8 y 9 muestran el diagrama general del Sistema de Monedero Virtual para Pagos Escolares y los actores que intervienen en el mismo, los cuales son: el alumno y el encargado.

Figura 8. Paquete general

Sistema de Monedero Virtual para pagos escolares

Abonar DineroRealizar

Pago

Eliminar Registro

Modificar Registro

Depend

Encargado

Alumno

Agregar Rgistro

Depend

Depend

Figura 9. Diagrama de dependencias

Sistema de monedero virtual para pagos escolares

EncargadoAlumno


21

3.3.2 Diagramas de casos de uso Cuando el usuario ingresa al sistema se muestran algunas opciones como son:

Pago Abono Alumnos Servicios Personal

Dentro de cada una de las opciones existen diferentes acciones que se realizan dentro de la base de datos. Dependiendo de la opción solicitada son los cambios que puede sufrir la base de datos, es decir, si se eligió Pago se realiza una consulta a la base de datos para mostrar una lista con todos los servicios que se pueden pagar y se piden los datos para realizar el pago. Si la elección fue Alumnos, Servicios o Personal, las operaciones que se pueden realizar son:

Agregar un nuevo registro Eliminar Modificar

Pago de Servicios

Figura 10. Caso de Uso Pagar

Caso de uso UC3: Pagar Actor Principal: Encargado.


22

Personal involucrado e intereses: Encargado: Quiere que la entrada al sistema sea rápida y precisa. Quiere que no existan errores de pago. Quiere poder llevar un registro de los pagos que han realizado los alumnos. Quiere que se registren las transacciones de manera correcta. Quiere que se puedan generar los comprobantes. Precondiciones: Identificación del encargado. Que el alumno cuente con una contraseña. Garantías de éxito: Se ingresa al sistema de forma sencilla. Se evalúan los datos del alumno manera correcta. Se acepta la realización del cobro. Se registra la transacción. Se genera un comprobante de pago. Escenario principal de éxito:

1. El encargado ingresa al portal. 2. El encargado ingresa su nombre y contraseña. 3. El sistema realiza la autenticación del usuario. 4. El sistema muestra una página para iniciar la realización del cobro. 5. El encargado acepta la realización. 6. El encargado imprime el comprobante.

Extensiones (o flujos alternativos): Como en cualquier momento el sistema falla, es preciso dar soporte a la recuperación y registro correcto para asegurar que los estados de una transacción puedan recuperarse.

1. El alumno reinicia el sistema, ingresa nuevamente sus datos para iniciar sesión, y solicita la recuperación al estado anterior.

2. El sistema reconstruye el estado anterior. 2a. El sistema detecta anomalías intentando la recuperación:

2a1. Sistema informa del error al alumno, registra el error y entra a un estado limpio.

2a2. El encargado comienza una nueva sesión. 3a. Numero de boleta no válido. 3a1. El sistema rechaza la entrada y señala el error. 3b. El formato del número de boleta no es válido. 3b1. El sistema señala el error y pide nuevamente sus datos.

3b2. El encargado cancela la transacción 4a. El sistema no muestra la pagina de cobro.

4a1. Sistema informa del error, registra el error y actualiza el sistema. 4a2. El encargado cancela la operación y reinicia el sistema.

5a. No se puede realizar la operación. 5a1. El sistema avisa el error al encargado y pide nuevamente que se acepte la operación.

6a. No se puede generar el comprobante. 6a1. El sistema envía un error al encargado y pide que ingrese la orden de impresión de comprobante.


23

Figura 11. Caso de Uso Realizar Cobro

Caso de uso UC4: Realizar Cobro. Actores Principales: Encargado y Alumno. Personal involucrado e intereses: Encargado: Quiere que la entrada al sistema sea rápida y precisa. Quiere que no existan errores de pago. Quiere poder ingresar las cantidades sin problemas. Quiere que se registren las transacciones de manera correcta. Alumno: Quiere que la entrada al sistema sea rápida y confidencial. Quiere contar con opciones que permitan seleccionar un servicio específico. Quiere que al registrar sus pagos el saldo de su cuenta este seguro y no pueda ser modificado, a menos que haya hecho uso de el. Quiere poder contar con un comprobante que sea generado por el sistema. Precondiciones: Que el alumno cuente con una contraseña y su NIP. Garantías de éxito: Se ingresa al sistema de forma sencilla. Se evalúa el saldo disponible de manera correcta. Se registra el pago. El descuento se realiza de manera correcta. Se registra la operación y se afecta la base de datos. Escenario principal de éxito:

1. El encargado ingresa al portal de realización de cobro. 2. El alumno su número NIP. 3. El sistema hace la validación de este dato de forma correcta. 4. El sistema muestra una un campo para ingresar cantidad. 5. El sistema realiza la validación correcta del dato. 6. El sistema verifica que la cantidad a pagar del servicio es menor al saldo

disponible del alumno. 7. El sistema realiza la resta del monto del servicio al saldo disponible del

alumno. 8. El sistema actualiza la cuenta y verifica la transacción.


24


1. El encargado reinicia el sistema, ingresa nuevamente sus datos para iniciar sesión, y solicita la recuperación al estado anterior.


2a1 Sistema informa del error al encargado, registra el error y entra a un estado limpio.

2a2 El encargado comienza una nueva sesión. 3a. NIP no válido

3a1 El sistema rechaza la entrada y señala el error. 3b. El formato del NIP no es válido.

3b1 El sistema señala el error y pide nuevamente el dato. 3b2 El alumno cancela la sesión

4a. El campo de ingresar cantidad no se muestra. 4a1. Sistema informa del error al encargado, registra el error y actualiza el sistema. 4a2. El encargado cancela la operación y reinicia el sistema.

5a. La cantidad ingresada no es válida. 5a1. El sistema avisa el error al encargado y pide nuevamente que se elija un departamento.

5b. El formato de la cantidad no es válido. 5b1 El sistema señala el error y pide nuevamente el dato. 5b2 El encargado cancela la sesión

6a. El saldo disponible es insuficiente. 6a1. El sistema manda un aviso al usuario acerca de su saldo disponible y rechaza la entrada, regresando al primer portal.

6b. El precio del servicio tiene un formato incorrecto. 6b1. El sistema rechaza la entrada y pide al usuario que elije nuevamente el servicio a pagar.

7a. No se puede realizar la operación de descuento. 7a1. El sistema rechaza la entrada y pide al alumno que se actualice operación.

8a. El sistema no puede actualizar la cuenta. 8a1. El sistema envía un error al alumno, se registra el error y reinicia el

sistema. 8b. No se registro la transacción.

8b1. El sistema trata de actualizar el registro y envía un error pidiendo que el alumno vuelva a realizar la transacción.

9a. No se puede generar el comprobante. 9a1. El sistema envía un error al usuario y pide que ingrese la orden de impresión de comprobante.


25

Abonar Dinero

Abonar Dinero

Ingresar nombre y contraseña

Validación del número de boleta

Número no encontrado en la Bd

Número no válido

Ingresar número de boleta y cantidad Validar cantidad

Imprimir Comprobante

Include

Include

Administrador

Formato no validoExtend

Extend

Extend

Figura 12: Caso de Uso Abono de Dinero

Caso de uso UC1: Abonar dinero Actor Principal: Administrador Personal involucrado e intereses: Administrador: Quiere que la entrada al sistema sea rápida y precisa. Quiere que no existan errores en el abono de dinero. Quiere poder llevar un registro de los abonos que han realizado los alumnos. Quiere que se registren las transacciones de manera correcta. Quiere que se puedan generar los comprobantes de dichos abonos. Precondiciones: Que el alumno cuente con un número de boleta único. Garantías de éxito: Se ingresa al sistema de forma sencilla. Se registra el abono realizado. El incrementa el saldo disponible de manera correcta. Se actualiza la cuenta del alumno. Se registra la transacción. Se genera un comprobante de abono de dinero. Escenario principal de éxito:

1. El Administrador ingresa al portal. 2. El administrador ingresa su número de boleta del alumno y contraseña. 3. El sistema realiza la autenticación del alumno y solicita su nombre y

contraseña. 4. El sistema muestra un campo para ingresar la cantidad que se desea

abonar. 5. Se realiza la validación de la cantidad a abonar de manera correcta. 6. El Administrador acepta la operación. 7. El sistema suma la cantidad abonada al saldo disponible. 8. El sistema actualiza la cuenta y verifica la transacción. 9. El sistema genera un comprobante de abono con la fecha, hora, nombre

del alumno, número de boleta, folio y cantidad a abonar. 10. El Administrador imprime el comprobante de abono de dinero. 11. El Administrador cierra su sesión.


26


1. El Administrador reinicia el sistema, ingresa nuevamente sus datos para iniciar sesión, y solicita la recuperación al estado anterior.


2a1. Sistema informa del error al administrador, registra el error y entra a un estado limpio.

2a2. El alumno comienza una nueva sesión. 3a. Número de boleta inválido. 3a1. El sistema rechaza la entrada y señala el error. 3b. El formato del número de boleta es incorrecto.

3b1. El sistema señala el error y pide nuevamente sus datos. 3b2. El administrador cancela la sesión 4a. El sistema no muestra el campo para introducir la cantidad a abonar.

4a1. Sistema informa del error al administrador, registra el error y actualiza el sistema.

4a2. El administrador cancela la operación y reinicia el sistema. 5a. La cantidad insertada no es válida.

5a1. El sistema avisa el error al encargado y pide nuevamente que se elija un departamento.

6a. El formato de la cantidad abonada es incorrecto. 6a1. El sistema emite que existe un error, se registra el error y pide nuevamente se introduzca la cantidad a abonar. 6a2. El administrador tiene la opción de actualizar la página ó regresar al portal anterior.

7a. No se puede realizar la operación de incremento de crédito. 7a1. Sistema informa del error al administrador, registra el error y entra a un estado limpio.

7a2. El administrador emite la orden de aceptar abono. 8a. El sistema no puede actualizar la cuenta.

8a1. El sistema envía un error al alumno, se registra el error y reinicia el sistema.

8b. No se registro la transacción. 8b1. El sistema trata de actualizar el registro y envía un error pidiendo que el alumno vuelva a realizar la transacción.

9a. No se puede generar el comprobante. 9a1. El sistema envía un error al usuario y pide que ingrese la orden de impresión de comprobante.

10a. No se puede cerrar la sesión. 10a1. El sistema emite un error y lo registra, así mismo realiza la operación de actualización y finalmente pide al administrador que oprima el botón de cerrar sesión.


27

Agregar Registro

Agregar Registro

Ingresar folio Validar número de folio

Folio no encontrado en la Bd

´Folio no válido

Ingresar el nombre Validar nombre

Ingresar datos

Include

Include

Administrador

Formato no valido

Validar los datosInclude

Formato no valido

Aceptar ingreso

Extend

Extend

Extend

Extend

Ingresar nombre y contraseña

Solicitar contraseña

Datos no encontrado en la

Bd

Datos no válidos

Extend

Extend

Figura 13. Caso de Uso Agregar Registro

Caso de uso UC6 Agregar Registro Actores Principales: Administrador. Personal involucrado e intereses: Administrador: Quiere que la entrada al sistema sea rápida y precisa. Quiere que no existan errores en el ingreso de un servicio. Quiere ingresar los datos del servicio sin problemas. Quiere que se registre el nuevo servicio de manera correcta. Quiere que se actualice el sistema. Precondiciones: Que el administrador ya este registrado. Garantías de éxito: Se ingresa al sistema de forma sencilla. Se registra el nuevo ingreso. Se actualiza el sistema para visualizar el nuevo registro. Se registra la transacción. Escenario principal de éxito.

1. El administrador ingresa al portal. 2. El administrador ingresa su nombre y contraseña. 3. El sistema realiza la autenticación del administrador y solicita su

contraseña. 4. El sistema pide los datos del nuevo registro. 5. El administrador ingresa el folio, nombre y datos adicionales 6. El sistema hace una validación correcta de los datos ingresados. 7. El administrador acepta el ingreso. 8. El sistema verifica que el servicio ya esta registrado correctamente.


28


1. El administrador reinicia el sistema, ingresa nuevamente sus datos para iniciar sesión, y solicita la recuperación al estado anterior.


2a1 Sistema informa del error al administrador, registra el error y entra a un estado limpio. 2a2 El administrador comienza una nueva sesión.

3a. Nombre y/o contraseña no válida. 3a1 El sistema rechaza la entrada y señala el error.

3b. El formato del nombre y/o contraseña es incorrecto. 3b1 El sistema señala el error y pide nuevamente los datos.

3b2 El administrador cancela la sesión 4a. El sistema no pide los datos del nuevo servicio.

4a1. Sistema informa del error al encargado, registra el error y actualiza el sistema.

4a2. El administrador cancela la operación y reinicia el sistema. 5-6a. El folio, nombre y/o precio no son válidos.

5a1. El sistema avisa el error al administrador y pide nuevamente que se elija un departamento.

5b. El formato de los datos no es válido. 5b1 El sistema señala el error y pide nuevamente el dato. 5b2 El administrador cancela la sesión

5c. El servicio ya está registrado. 5c1 El sistema señala el error y pide al administrador que ingrese otros datos 5c2 El administrador cancela la sesión

7-8a. No se pude realizar la operación. 7a1. El sistema manda un aviso al usuario acerca de su saldo disponible y rechaza la entrada, regresando al portal anterior.


29

Eliminar Registro

Extend

Extend

Figura 14. Caso de Uso Eliminar Registro

Caso de uso UC7: Eliminar Registro Actor Principal: Administrador. Personal involucrado e intereses: Administrador: Quiere que la entrada al sistema sea rápida y precisa. Quiere que no existan errores durante la eliminación. Quiere que se realicen las transacciones de manera correcta. Quiere que se pueda actualizar la información en la base de datos. Precondiciones: Registro del administrador en el sistema, así como del registro a eliminar. Garantías de éxito: Se ingresa al sistema de forma sencilla. Se evalúan los datos del encargado manera correcta. Se acepta la eliminación. Escenario principal de éxito:

1. El administrador ingresa al portal. 2. El administrador ingresa su nombre e identificador. 3. El sistema realiza la autenticación y solicita la contraseña del

administrador. 4. El administrador ingresa la clave principal del registro. 5. El sistema hace una validación correcta de los datos ingresados. 6. El sistema verifica que el servicio seleccionado se pueda eliminar. 7. El administrador acepta la eliminación del registro. 8. El sistema verifica que el registro fue eliminado correctamente. 9. El administrador verifica que no aparezca el registro en la lista.


30



2. El sistema reconstruye el estado anterior. 2a. El sistema detecta anomalías intentando la recuperación.

2a1 El sistema informa del error al administrador, registra el error y entra a un estado limpio.

2a2 El administrador comienza una nueva sesión. 3a. Nombre y/o contraseña no válida. 3a1 El sistema rechaza la entrada y señala el error. 3b. El formato de la contraseña y/o nombre es incorrecto.

3b1 El sistema señala el error y pide nuevamente sus datos. 3b2 El administrador cancela el inicio de sesión. 4-5a. Folio y/o nombre no válido. 4-5a1 El sistema rechaza la entrada y señala el error. 4-5b. El formato del folio y/o nombre es incorrecto.

4-5b1 El sistema señala el error y pide nuevamente los datos del registro. 4-5b2 El administrador cancela la operación. 6a. El servicio elegido no se puede eliminar.

5-6a1. Sistema informa del error, registra el error y actualiza el sistema. 5-6a2. El administrador cancela la operación y regresa a la página anterior.

7-8a. La eliminación del servicio no se puede efectuar. 7-8a1. El sistema avisa el error, actualiza el sistema y pide que se selección

nuevamente una opción. 9a. El servicio todavía aparece en la lista.

9a1. El administrador pide la actualización del sistema. 9a2. El administrador vuelve a efectuar la operación de eliminación.


31

Modificar Registro

Figura 15. Caso de Uso Modificar Servicio

Caso de uso UC5: Modificar Registro Actor Principal: Administrador. Personal involucrado e intereses: Administrador: Quiere que la entrada al sistema sea rápida y precisa. Quiere que no existan errores durante la modificación. Quiere tener opciones para modificar campos. Quiere que se realicen las transacciones de manera correcta. Quiere que se pueda actualizar la información. Precondiciones: Registro del encargado en el sistema, así como de los datos a modificar. Garantías de éxito: Se ingresa al sistema de forma sencilla. Se evalúan los datos del encargado manera correcta. Se acepta la realización de modificación. Se actualizan los datos. Escenario principal de éxito:

1. El administrador ingresa al portal. 2. El administrador ingresa su nombre. 3. El sistema realiza la autenticación del administrador solicitando también

su contraseña. 4. El administrador ingresa la clave principal de dato a cambiar. 5. El sistema hace una validación correcta de los datos ingresados. 6. El sistema muestra un menú con los campos que se pueden modificar. 7. El administrador elige el campo que desea modificar.


32

8. El sistema verifica si los campos seleccionados se pueden modificar. 9. El administrador ingresa los datos nuevos. 10. El administrador selecciona la opción de realizar modificación. 11. El sistema verifica que el dato se cambio correctamente. 12. El administrador verifica que se hayan actualizado los datos.




2a1 El sistema informa del error al alumno, registra el error y entra a un estado limpio. 2a2 El administrador comienza una nueva sesión.

3a. Nombre y/o contraseña no válida. 3a1 El sistema rechaza la entrada y señala el error. 3b. El formato de la contraseña y/o nombre es incorrecto. 3b1 El sistema señala el error y pide nuevamente sus datos. 3b2 El administrador cancela el inicio de sesión. 4a. Folio y/o nombre no válido. 4a1 El sistema rechaza la entrada y señala el error. 4b. El formato del folio y/o nombre es incorrecto. 4b1 El sistema señala el error y pide nuevamente los datos.

4b2 El administrador cancela la operación. 5-6a. No se puede mostrar el menú de los campos. 5-6a1. Sistema informa del error, registra el error y actualiza el sistema.

5-6a2. El administrador cancela la operación y regresa a la página anterior. 7a. No se puede elegir algún campo. 7a1. El sistema avisa el error, actualiza el sistema y pide que se selección

nuevamente una opción. 8a. El campo seleccionado no se puede modificar. 8a1. El sistema envía un error al encargado y pide que elija otra opción. 9a. Los nuevos datos no se pueden insertar.

9a1. El sistema muestra un error y lo registra, posteriormente actualiza el sistema y pide que se ingresen nuevamente los datos.

10-12a El sistema no realiza los cambios requeridos por el encargado. 10-12a1. El sistema genera un error, lo muestra y actualiza el sistema

pidiendo que se emita otra vez la orden de realizar cambio.


33

3.3.3 Diagramas de actividades

ABONAR DINERO

ALUMNOADMINISTRADOR SISTEMA

Ingresar numero deboleta

IngresarCantidad

Mandar a imprimir

Valido? No

Valido?

Registrar cantidad

Imprimir?

Expedir comprobante

Si

Si

No

No

Si

Figura 16. Diagrama de Actividades, Abono de Dinero


34

REALIZAR PAGO

ALUMNO

Seleccionar servicio

Mandar a imprimir

PERSONAL

Valido?

Si

No

No

Si

Expedir comprobante

Si

No

No

Si

SISTEMA

Obtener total

Obtener monto

Enviar mensaje

Registrar pago

Imprimir?

Ingresar numero deboleta

Valido?

IngresarNIP

Suficiente?

Verificar monto

Más pagos?

Si

No

Figura 17. Diagrama de Actividades, Pago Directo


35

MODIFICAR REGISTRO

ADMINISTRADOR SISTEMA

Asignar codigo

Usuario

Valido?No

Contraseña

Si

Modificar Registro

Eliminar Registro

Ingresarnombre

Elegir cambio

Agregar Registro

Valido?

Si

No

Valido?

Borar servicio

Ingresarnombre

Ingresarcodigo

Eliminar?

Ingresar dato nuevo

Ingresar datos

No

Si

Registrarcambio

No

Si

Figura 18. Diagrama de actividades, Modificar Registro


36

3.3.4 Modelo Entidad-Relación La Base de Datos (BD) que forma parte de la capa de Modelo dentro del sistema, contiene 4 entidades, los atributos y las relaciones entre ellas se muestran en la figura 19.

Figura 19. Modelo Entidad-Relación

3.3.5 Diagrama de clases En las figura 20 muestra el diagrama de clases del sistema.

manejamaneja

1 1

111

utiliza

invocainvoca

invoca

emplea

emplea

emplea

emplea

emplea

utiliza

utiliza

utiliza

AlimnoVOPersonalVO

ServicioVO

MovimientoDAOServicioDAO

MovimientoVO

MovimientoACTIONServcioACTION

AlumnoFORM

MovimientoFORM

PersonalFORM

ServicioFORM ConexionBD DAOException

1

1

1

1

1

1

invocaPersonalDAOPersonalACTION

1

1 1

1

1

1

1

1 1

invocaAlumnoDAO AlumnoACTION

111

1

11

Kerberos

1

1

1

Figura 20. Diagrama de Clases


37

En la figura 20 se muestra la relación que existe entre las clases DAO, VO, FORM y ACTION. La figura 21 muestra los atributos y los métodos que contienen las clases FORM y ACTION. Las clases ACTION utilizan los métodos de las clases DAO. La figura 22 muestra los atributos y métodos de las clases VO y DAO.

AlumnoFORM

-noBoleta:int-nombre:string-apellidoPaterno:string-apellidoMaterno:string-semestre:string-grupo:string-turno:char-dirección:string-municipio:string-CP:string-saldo:float-NIP:string-nameUS:string-activo:char-sesion:char

+getNoBoleta():int+set(noBoleta:int):void+getNombre():string+set(nombre:string):void+getApellidoPaterno():string+set(apellidoPaterno:string):void+getApellidoMaterno():string+set(apellidoMaterno:string):void+getSemestre():string+set(semestre:string):void+getGrupo():string+set(grupo:string):void+getTurno():char+set(turno:char):void+getDirección():string+set(dirección:string):void+getMunicipio():string+set(municipio:string):void+getCP():string+set(CP:string):void+getSaldo():float+set(saldo:float):void+getNIP():string+set(NIP:string):void+getNameUS():string+set(nameUS:string):void+getActivo():char+set(activo:char):void+getSesion():char+set(sesion:char):void

ServicioFORM

-claveServicio:string-idPersonal:string-descripción:string-precio:float-departamento:string

+getClaveServicio():string+set(claveServicio:string):void+getIdPersonal():string+set(idPersonal:string):void+getDescripción():string+set(descripción:string):void+getPrecio():float+set(precio:float):void+getDepartamento():string+set(departamento:string):void

MovimientoFORM

-idMovimiento:int-noBoleta:int-claveServicio:string-cantidad:int-montoTotal:float-fecha:date-tipoMovimiento:char

+getIdMovimiento:int():int+set(idMovimiento:int):void+getNoBoleta():int+set(noBoleta:int):void+getClaveServicio():string+set(claveServicio:string):void+getCantidad():int+set(cantidad:int):void+getMontoTotal():float+set(montoTotal:float):void+getFecha():date+set(fecha:date):void+getTipoMovimiento():char+set(tipoMovimiento:char):void

PersonalFORM

-idPersonal:string-nombre:string-apellidoPaterno:string-apellidoMaterno:string-tipoPersonal:char-nameUS:string-sesion:char-activo:char

+getidPersonal():string+set(idPersonal:string):void+getNombre():string+set(nombre:string):void+getApellidoPaterno():string+set(apellidoPaterno:string):void+getApellidoMaterno():string+set(apellidoMaterno:string):void+getTipoPersonal():char+set(tipoPersonal:char):void+getNameUS():string+set(nameUS:string):void+getActivo():char+set(activo:char):void+getSesion():char+set(sesion:char):void

AlumnoACTION

execute(mapping:ActionMapping, form:ActionForm, request:HttpServletRequest, response:HttpResponse:ActionForward):ActionForward

ServicioACTION


MovimientoACTION


PersonalACTION


Figura 21. Clases ACTION y clases FORM


38

AlumnoVO

-noBoleta:int-nombre:string-apellidoPaterno:string-apellidoMaterno:string-semestre:string-grupo:string-turno:char-dirección:string-municipio:string-CP:string-saldo:float-NIP:string

+getNoBoleta():int+set(noBoleta:int):void+getNombre():string+set(nombre:string):void+getApellidoPaterno():string+set(apellidoPaterno:string):void+getApellidoMaterno():string+set(apellidoMaterno:string):void+getSemestre():string+set(semestre:string):void+getGrupo():string+set(grupo:string):void+getTurno():char+set(turno:char):void+getDirección():string+set(dirección:string):void+getMunicipio():string+set(municipio:string):void+getCP():string+set(CP:string):void+getSaldo():float+set(saldo:float):void+getNIP():string+set(NIP:string):void

AlumnoDAO

AlumnoVO alumnoVO

+insertarAlumno(alumnoVO:AlumnoVO):int+borrarAlumno(noBoleta:int):int+modificar(alumnoVO:AlumnoVO):int+buscarAlumno(noBoleta:int):int+ActivarSesion(noBoleta:int):int+CerrarSesion(noBoleta:int):int+consultaPorBolleta(noBoleta:int):AlumnoVO

ServicioDAO

ServicioVO servicioVO

+agregar(servicioVO:ServicioVO):int+borrarServicio(claveServicio:string):int+modificar(String claveServ, String atributo, String valor):int+listaServicios():ServicioVO+buscarServicio(String clave Servicio):ServicioVO

ServicioVO

-claveServicio:string-idPersonal:string-descripción:string-precio:float-departamento:string

+getClaveServicio():string+set(claveServicio:string):void+getIdPersonal():string+set(idPersonal:string):void+getDescripción():string+set(descripción:string):void+getPrecio():float+set(precio:float):void+getDepartamento():string+set(departamento:string):void

MovimientoVO

-idMovimiento:int-noBoleta:int-claveServicio:string-cantidad:int-montoTotal:float-fecha:date-tipoMovimiento:char

+getIdMovimiento:int():int+set(idMovimiento:int):void+getNoBoleta():int+set(noBoleta:int):void+getClaveServicio():string+set(claveServicio:string):void+getCantidad():int+set(cantidad:int):void+getMontoTotal():float+set(montoTotal:float):void+getFecha():date+set(fecha:date):void+getTipoMovimiento():char+set(tipoMovimiento:char):void

MovimientoDAO

MovimientoVO movimientoVO

+insertarAbono(int noBoleta,String clavePersonal, float cantidad):int+insertarPago(int noBoleta,String claveServ, int cantidad):int+pagosMES(int noBoleta,String mes):MovimientoVO

PersonalDAO

PersonalVO personalrVO

+insertarPersonal(personalVO:PersonalVO ):int+borrarPersonal(idPersonalr:string):int+modificar(String idPersonal, String atributo, String valor):int+consultaPorID(String idPersonal):PersonalVO+CerrarSesion(String idPersonal):int+ActivarSesion(String idPersonal):int

PersonalVO

-idPersonal:string-nombre:string-apellidoPaterno:string-apellidoMaterno:string-contraseña:string-tipoPersonal:char

+getidPersonal():string+set(idPersonal:string):void+getNombre():string+set(nombre:string):void+getApellidoPaterno():string+set(apellidoPaterno:string):void+getApellidoMaterno():string+set(apellidoMaterno:string):void+getContraseña():string+set(contraseña:string):void+getTipoPersonal():char+set(tipoPersonal:char):void

Kerberos

+nameUS:String +passPrinc:String +passNew:String

+AddPrincipales(String nameUS, String passPrinc):int+CambiarPassword(String nameUS, String passPrinc, String passNew):int+DelPrincipal(String nameUS):int+conecta():void+desconecta():void

ConexionBD

-URL:String-usuario:String-password:String-con:Connection-stmt:Statement

+CerrarConexionBD():void+getCon():Connection+setCon(Connection):void+obtenerStatement():Statement

DAOException

+DAOException(String);

Figura 22. Clases VO y clases DAO


39

3.4 Desarrollo 3.4.1 Modelo Relacional

En la figura 17 se muestra cada uno de los atributos que contienen las tablas de la BD (Base de Datos) que fue implementada para el desarrollo del sistema.

Figura 23. Modelo Relacional

Para el desarrollo de la base de datos se utilizó el SGBD MySQL en su versión 5.0. MySQL es multiplataforma lo cual es adecuado para la aplicación además de que en la actualidad es el más utilizado en aplicaciones Web con java, consume pocos recursos aumentando su velocidad de respuesta, lo cual es esencial para el sistema. Para interactuar con la base de datos se programaron procedimientos almacenados que realizan cambios significativos en la BD, estos se mandan ejecutar desde clases Action de Java. Los procedimientos almacenados que se programaron son: insertar_alumno, insertar_personal, insertar_servicio, eliminar_alumno, eliminar_servicio, eliminar_personal, modif_alumno, modif_servicio, modif_personal, realizar_abono, pago, buscar_alumno. Dentro de estos procedimientos se efectúan algunas consultas y sentencias en cadena ocasionando cambios en más de dos tablas.


40

El código mostrado en la tabla 5 muestra las sentencias que se siguen para agregar un nuevo registro dentro de la tabla de servicio que se encuentra en la base de datos. DELIMITER // CREATE PROCEDURE nuevo_servicio (in clave VARCHAR(10), in Personal VARCHAR(10), in descripcion VARCHAR(40), in precio FLOAT, in departamento VARCHAR(20)) BEGIN declare msn varchar(20); if exists(select * from personal where idPersonal = Personal) /*verificar que la persona que registra el servicio este registrada*/ then if not exists(select * from servicio where claveServicio = clave) /*verificar que el servicio aun no este registrado*/ then insert into servicio values (clave, Personal, descripcion, precio, departamento); else set msn = 'El servicio ya esta registrado'; select msn; end if; else set msn = 'No puedes registrar un servicio'; select msn; end if; END //

Tabla 5. Código Procedimiento Almacenado Cada procedimiento almacenado funciona de manera similar para su manipulación en Eclipse, el resultado que manda es de tipo entero y la respuesta se presenta en un JSP. 3.4.2 Implementación de Struts Para llevar a cabo el uso de Struts se utilizó MyEclipse, el cual permite configurar un proyecto que soporte este framework. Al añadir el manejo de Struts en MyEclipse se modifica el archivo web.xml del proyecto y se añade el archivo struts-config.xml. El diagrama que se encuentra en dicho archivo es una representación visual de un fichero de configuración de Struts que muestra cómo el flujo del escenario va de componente a componente. La figura 24 muestra un fragmento del fichero struts-config.xml.

Figura 24. Archivo de configuración struts-config.xml(Logeo)


41

Para que el usuario pueda interactuar con el sistema se crearon páginas JSP´s donde se pide al usuario que introduzca algunos datos, en el caso de un alumno se pide su número de boleta, nombre de usuario y contraseña. Una vez que el alumno ingresa los datos, el sistema realiza una consulta a la base de datos de Kerberos mediante la clase loginAAction.java y la clase JaasAcn.java verifica que estos estén registrados, validando así que el usuario existe. En la tabla 6 se observa el código de la clase loginAAction.java. public class LoginAAction extends Action { public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { LoginAForm loginAForm = (LoginAForm) form; // objeto que manipula la session HttpSession session = request.getSession(); AlumnoDAO alumnoDAO = null; ServicioDAO servicioDAO=null; AlumnoVO alumnoVO = null; ServicioVO servicioVO=null; try {// instancia de las clases DAO alumnoDAO = new AlumnoDAO("jdbc:mysql://localhost/pagosEscolares","root",""); servicioDAO = new ServicioDAO("jdbc:mysql://localhost/pagosEscolares","root",""); JaasAcn ja=new JaasAcn(); // instancia de las clases VO alumnoVO = new AlumnoVO(); servicioVO= servicioDAO.getListaServicio(); String nombre=loginAForm.getNombre(); System.out.println("Este es el nombre:"+nombre); int autKER=ja.conecta(loginAForm.getNombre(),loginAForm.getPassword()); System.out.println("nombre loginA:"+loginAForm.getNombre()); // recupera los datos del usuario especificado en la forma alumnoVO=alumnoDAO.consultaPorBoleta(loginAForm.getBoleta()); alumnoVO.setNameUS(nombre); if(autKER==1) { session.setAttribute("alumno",alumnoVO); session.setAttribute("servicio",servicioVO); return mapping.findForward("valido1"); } else if (autKER==2) return mapping.findForward("error1"); } catch (DAOException e) { // TODO Auto-generated catch block e.printStackTrace(); } return null; } }

Tabla 6. Código de la clase loginAAction.java


42

En función del resultado de la ejecución de la clase loginAAction.java, se decidirá que JSP se presentará como respuesta, es decir, si los datos ingresados son correctos, se redirigirá a la JPS que corresponda al flujo mostrado en la figura 24, el cual indica que la JSP que será mostrada al alumno es la paginaInicial.jsp, de lo contrario se mostrará la página error.jsp. 3.4.3 Validación Struts ofrece una facilidad adicional para validar los campos de entrada que ha recibido. Para utilizar esta característica, se integra el siguiente método dentro de las clases ActionForm. La clase validate indica si se realizará la validación previa de los datos de entrada. Si la invocación no es satisfactoria no se llegará a invocar al Action solicitado. El código que se muestra en la tabla 7 contiene algunas validaciones para los campos que se encuentran en la JSP alumno.jsp. Cuando el administrador desea dar de alta un nuevo alumno los campos que se encuentren vacíos o que contengan caracteres en vez de números son detectados a través de la clase validate y busca el mensaje correspondiente a ese campo dentro del archivo ApplicationResources.properties, que contiene etiquetas como:

errors.municipio.requerido public ActionErrors validate(ActionMapping mapping, HttpServletRequest request); { if((municipio==null)||(municipio.length()<1)) errors.add("municipio",new ActionError("errors.minicipio.requerido")); if((colonia==null)||(colonia.length()<1)) errors.add("colonia", new ActionError("errors.colonia.requerido")); if((direccion==null)||(direccion.length()<1)) errors.add("direccion", new ActionError("errors.direccion.requerido")); if((CP==null)||(CP.length()>5)) errors.add("CP", new ActionError("errors.CP.requerido")); return errors; }

Tabla 7. Clase validate

Para que este proceso se lleve acabo dentro de las JSP donde se encuentran los campos a evaluar se requiere que se incluya la etiqueta <html:errors/> para mostrar la lista de errores detectados por el formBean. Lo que se garantiza empleando este método es que cuando el usuario ingresa una cadena “abc” en un campo numérico inmediatamente se genera un error y se asigna el valor 0 al campo de tipo entero.


43

3.4.4 Manejo de Transacciones La manera más sencilla de garantizar que se llevó a cabo una transacción dentro de la base de datos de MySQL es haciendo uso de las tablas tipo InnoDB debido a que son seguras y fáciles de recuperar si se produce algún fallo en el servidor, ya que las consultas se ejecutan o no en su totalidad.

Otras de sus características son:

- Recuperación automática ante fallas. Si MySQL se da de baja de una forma anormal, InnoDB automáticamente completará las transacciones que quedaron incompletas.

- Integridad referencial. Ahora se pueden definir llaves foráneas entre tablas InnoDB relacionadas para asegurarse de que un registro no puede ser eliminado de una tabla si aún está siendo referenciado por otra tabla.

- Bloqueo a nivel de filas. Al usar tablas MyISAM, y tener consultas muy grandes que requieren de mucho tiempo, simplemente no se podían ejecutar más consultas hasta que terminarán las consultas que estaban en ejecución. En cambio, las tablas InnoDB usan bloqueo a nivel de filas para mejorar de manera impresionante el rendimiento.

- SELECTs sin bloqueo. El motor InnoDB usa una técnica conocida como multi-versioning (similar a PostgreSQL) que elimina la necesidad de hacer bloqueos en consultas SELECT muy simples. Ya no será necesario molestarse porque una simple consulta de sólo lectura está siendo bloqueada por otra consulta que está haciendo cambios en una misma tabla.

Cuando se crean las tablas InnoDB uno de los parámetros que se activa de manera instantánea es el autocommit, el cual garantiza que las operaciones sean realizadas en su totalidad, sin embargo, para poder controlar de manera externa dichas transacciones se deshabilito dicho comando a través de la clase ConexiónBD.java que se tiene en el sistema dentro de la carpeta DAO. El código de la clase ConexiónBD.java se muestra en la tabla 8.

public class ConexionBD { private Connection con=null; private Statement stmt=null; public ConexionBD(String url,String usuario,String password) throws DAOException { try { Class driver= Class.forName("com.mysql.jdbc.Driver"); con = DriverManager.getConnection(url,usuario,password); con.setAutoCommit(false); con.setTransactionIsolation(java.sql.Connection.TRANSACTION_SERIALIZABLE); stmt= con.createStatement(); } catch (ClassNotFoundException e) { throw new DAOException("Driver no encontrado"); } catch (SQLException e) { throw new DAOException("Error al establecerse la conexion"); } }


44

public Statement obtenerStatement(){ return stmt; } public void CerrarConexionBD()throws DAOException{ try { con.close(); } catch (SQLException e) { throw new DAOException("Error al cerrar conexion"); } } public Connection getCon() { return con; } public void setCon(Connection con) { this.con = con; } }

Tabla 8. Clase ConexiónBD.java

Como se el comando autocommit queda deshabilitado cada vez que se ejecuta algún procedimiento o método que se encuentra dentro de las clases DAO que utilizan a la clase conexión es necesario utilizar dentro de estos métodos las sentencias commit y rollback.

El commit funciona para asegurar que la transacción se completo de manera adecuada, sin embargo si el sistema tiene alguna falla el rollback se encarga de deshacer lo que no se ha completado para ayudar al sistema a restablecerse rápidamente.

La tabla 9 muestra las sentencias java que manejan estos comandos. public int borrarAlumno(int noBoleta,String idP) throws DAOException { int sms = 0; try { // Llamar al SP para borrar un alumno ResultSet conjuntoResultados = stmt.executeQuery( "call eliminar_alumno(" + noBoleta +",'"+idP+ "');" ); while ( conjuntoResultados.next() ) { sms = conjuntoResultados.getInt("msn"); if(sms>0) (conexionBD.getCon()).commit(); else (conexionBD.getCon()).rollback(); } // JOptionPane.showMessageDialog(null, uno ); } catch (SQLException e) { throw new DAOException("Error al eliminar el registro"); } return sms; }

Tabla 9. Sentencias Java para el manejo de los comandos commit y rollback.

45

3.4.5 Configuración de SSL en Tomcat Para realizar la configuración de Tomcat para acceder a las aplicaciones Web empleando HTTP sobre SSL se llevaron acabo los siguientes pasos: Se descargo el paquete JSSE encontrado en http://java.sun.com/products/jsse/ el cual incluye los jars necesarios para utilizar el paquete de seguridad. Estos archivos con extensión *.jar fueron colocados en el directorio c:/Archivos de Programa/java/jdk1.5 /jre/lib/ext. Se requirió modificar el archivo Server.xml para permitir el uso del puerto seguro 8443, para ello se activa la parte de código que se muestra en la tabla 10:  

Tabla 10. Archivo Server.xml

Debido a que se va a hacer uso del protocolo SSL es necesario la creación de un certificado autofirmado. Para crear el certificado autofirmado primero se debe crear un almacén de claves haciendo uso de la consola de Windows en la cual se ejecuta la sentencia (Figura. 25): %JAVA_HOME%\bin\keytool –genkey –alias tomcat –keyalg RSA

Figura 25. Ejecución de keytool

Posteriormente se ingresa la clave que tendrá el almacén de claves (Figura 26) que se pedirá cada vez que se descargue el certificado del servidor. Este almacén ayuda a proporcionar mayor seguridad, debido a que guarda la información del servidor, como su certificado, su clave pública y privada, que posteriormente se utilizan cuando se accede al sistema mediante el canal seguro SSL.


46

Figura 26. Ingresar contraseña

A continuación se ingresa el nombre, apellido, organización, estado, localidad y código del país, en la figura 27 se muestra un ejemplo de los datos que se deben ingresar.

Figura 27. Datos del certificado

La contraseña que pide para Tomcat de preferencia debe ser la misma que se introdujo para el almacén de datos.

Una vez que se crea el proceso, se debe de generar un archivo llamado .keystore en la carpeta de documents and settings que se encuentra en la unidad C.


47

Cada vez que un usuario desea ingresar al sistema, el archivo .keystore es consultado mediante la contraseña que se dio al inicio, posteriormente busca su clave pública y privada si el usuario exige ver el certificado creado y garantizar que esta firmado por el servidor.

Figura 28. Ubicación del keystore

Una vez que se inicia Tomcat 5.0 mediante el navegador https://localhost:8443/ se muestra en pantalla la opción para visualizar el certificado que fue creado durante la configuración.

Figura 29. Certificado del Servidor


48

Una vez que es aceptado el certificado, si la configuración fue realizada de manera correcta, se podrá visualizar en la pantalla el sitio de Tomcat a través del puerto 8443 y https.

Figura 30. Tomcat con https

3.4.6 Autenticación Kerberos v5 Se realizó la configuración de un servidor Kerberos en LINUX, debido a que se requiere tener un Centro Distribuidor de Claves (KDC) que permita tener una conexión directa con la BD kerberos y el MIT (Instituto Tecnológico de Massachusetts) creador de este protocolo proporciona dentro de su página software para instalar y configurar este sistema en LINUX. Kerberos se instaló en Fedora 6. Para configurar Kerberos V5 se requiere modificar los archivos krb5.conf y kdc.conf los cuales se encuentran en la ruta /etc/krb5.conf y usr/local/var/krb5kdc/kdc.conf, respectivamente.

El archivo krb5.conf contiene la información de la configuración de Kerberos, incluyendo las localizaciones del Centro Distribuidor de Claves(KDC) y de los servidores del administrador para los reinos de interes de Kerberos, los defectos para el reino actual y para los usos de Kerberos, y los mappings de hostnames sobre reinos de Kerberos. En la tabla 11 se muestra el codigo del archivo krb5.conf.


49

[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = PAGOS.COM // nombre del reino PAGOS dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes [realms] PAGOS.COM = { kdc = kerberos.pagos.com:88 admin_server = kerberos.pagos.com:749 default_domain = pagos.com } [domain_realm] .pagos.com = PAGOS.COM pagos.com = PAGOS.COM [kdc] profile = /usr/local/var/krb5kdc/kdc.conf Direction del KDC [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }

Tabla 11. Codigo del archivo krb5.conf

El archivo kdc.conf contiene los archivos que Kerberos utiliza por default para la emisión de tickets. La tabla 12 muestra el código de dicho archivo.

[kdcdefaults] kdc_ports = 750,88 [realms] PAGOS.COM = { database_name = /usr/local/var/krb5kdc/principal Localización y nombre de la BD admin_keytab = FILE:/usr/local/var/krb5kdc/kadm5.keytab acl_file = /usr/local/var/krb5kdc/kadm5.acl key_stash_file = /usr/local/var/krb5kdc/.k5.PAGOS.COM kdc_ports = 750,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s }

Tabla 12. Codigo del archivo kdc.conf


50

La creación de la Base de Datos (BD) se hace mediante el comando: kdbc_util. De la siguiente manera:

[ root@localhost ~]# /usr/local/sbin/kdb5_util create -r PAGOS.COM -s

Al ejecutar esta sentencia se crean 4 archivos: dos archivos de BD principal.db y principal.ok, un archivo de administración para la BD principal.kadm5, un archivo que sirve como cerradura para la base de datos principal.kadm5.lock.

Después es necesario crear un archivo ACL (Lista de Control de Acceso), este archivo es utilizado por el Kadmind para controlar a los usuarios y determinar los permisos que tienen para realizar ver o modificar los archivos de la base de datos de Kerberos. Por lo tanto es importante que al crear este archivo ACL este contenga por lo menos un el nombre de un administrador, en este caso dicho administrador es: */[email protected] *

Este archivo debe tener la siguiente ruta: /usr/local/var/krb5kdc/kadm5.acl

Una vez creado este archivo que contiene el nombre del administrador se debe agregar en la base de datos de Kerberos. Los pasos a seguir se encuentran en la tabla 13.

shell% /usr/local/sbin/kadmin.local kadmin.local: addprinc admin/[email protected] NOTICE: no policy specified for "admin/[email protected]"; assigning "default". Enter password for principal admin/[email protected]: <= Introducir el Password Re-enter password for principal admin/[email protected]: <= Repetir en password Principal "admin/[email protected]" created. kadmin.local:

Tabla 13. Código para agregar un administrador.

Posteriormente se procede a la creación del archivo que servirá como llave para poder acceder mediante el Kadmind y descifrar si el usuario que quiere acceder a la base de datos esta registrado y que permisos tiene. A este archivo se le denomina Keytab. Este archivo debe contener las entradas para los archivos principales kadmin/admin y kadmin/changepw, las cuales se crean automáticamente al ejecutar los pasos que muestra la tabla 14: shell% /usr/local/sbin/kadmin.local kadmin.local: ktadd -k /usr/local/var/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw Entry for principal kadmin/admin with kvno 5, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/usr/local/var/krb5kdc/kadm5.keytab. Entry for principal kadmin/admin with kvno 5, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/usr/local/var/krb5kdc/kadm5.keytab. Entry for principal kadmin/changepw with kvno 5, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/usr/local/var/krb5kdc/kadm5.keytab. Entry for principal kadmin/changepw with kvno 5, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/usr/local/var/krb5kdc/kadm5.keytab. kadmin.local: quit shell%

Tabla 14. Creación del archivo Keytab


51

Para probar que el servidor Kerberos se haya configurado correctamente se debe crear otro usuario en la base de datos siguiendo el procedimiento descrito en la Tabla 4, y posteriormente se ejecutan la sentencia login.krb5 desde el Shell, esperando que el sistema pida que se ingresa el nombre de usuario y su password y permitiendo la entrada a la base de datos de Kerberos. 3.4.7 Implementación de JAAS El Servicio de Autenticación y Autorización de Java (JAAS) es un sistema de APIs que permita a servicios autenticar y hacer cumplir controles de acceso sobre usuarios. Este paquete se utilizó con el fin de lograr la comunicación desde Windows con el Servidor Kerberos para realizar la autenticación de usuarios que desean ingresar al sistema. La tabla 15 muestra el código del archivo de configuración, en el cual se especifica que se utilizará Krb5LoginMoldule que es el módulo en java para Kerberos. /** Login Configuration for the JaasAcn and ** JaasAzn Applications **/ JaasSample { com.sun.security.auth.module.Krb5LoginModule required; };

Tabla 15. Archivo de configuración, jaas.conf. En la tabla 16 se observa el código de la clase JaasAcn.java, donde se agregan propiedades al sistema, donde se especifican: el nombre del reino de Kerberos, PAGOS.COM; el KDC, kerberos.pagos.com, y el nombre del archivo de configuración, jaas.conf. public class JaasAcn { public int conecta(String nom, String pass) { System.setProperty("java.security.krb5.realm","PAGOS.COM"); System.setProperty("java.security.krb5.kdc","Kerberos.pagos.com"); System.setProperty("java.security.auth.login.config","c:\\jaas.conf"); LoginContext lc = null; try { lc = new LoginContext("JaasSample", new Prueba(nom,pass)); } catch (LoginException le) { System.err.println("Cannot create LoginContextL. " + le.getMessage()); System.exit(-1); } catch (SecurityException se) { System.err.println("Cannot create LoginContextS. " + se.getMessage()); //System.exit(-1); }


52

try { // attempt authentication lc.login(); } catch (LoginException le) { System.err.println("Authentication failed:"); System.err.println(" " + le.getMessage()); //System.exit(-1); return 2; } System.out.println("Authentication succeeded!"); return 1; } }

Tabla 16. Clase JaasAcn.java La clase JaasAcn.java contiene los parámetros necesarios que debe ingresar el usuario para autenticarse con Kerberos, en este caso su nombre y contraseña, una vez que se ingresan esta clase manda llamar a LoginModule a través del LoginContext especificado en el archivo jaas.conf. Al correr esta clase se puede verificar por medio de mensajes que emite si la autenticación fue satisfactoria o tuvo alguna falla. 3.4.8 Implementación de Firma Digital El algoritmo Digital Signatura Algorithm o Algoritmo de Firma Digital (DSA) sirve para generar y/o verificar la firma para el mensaje, a partir del resumen de éste. DSA es un estándar que hace uso de algoritmos como el RSA o el Secure Hash Algorithm (Algoritmo de Hash Seguro SHA), lo que significa que la función de resumen o hash se especifica con dichos algoritmos. DSA fue publicado por el Instituto Nacional de Tecnología y Estándares Norteamericano (NIST) en el estándar llamado Digital Signatura Standard o Estándar de firma digital (DSS). DSS fue seleccionado por el NIST con ayuda de la National Security Agency o Agencia de Seguridad Nacional (NSA) para ser el estándar de autenticación digital del gobierno de los Estados Unidos a partir de mayo 19 de 1994. Lo que quiere decir que es un algoritmo probado y que ofrece altos niveles de seguridad ya que no se conocen ataques eficientes contra este algoritmo, sólo existen problemas con un conjunto de números primos, pero son fácilmente evitables si se siguen los sistemas adecuados de generación de claves. Es posible manejar el estándar DSA a través del paquete de seguridad de Java el cual contiene clases que proporcionan funciones criptográficas. Las herramientas que incluye este paquete ayudan a realizar los resúmenes de un mensaje, firmar un documento, crear claves públicas y privadas, etc.


53

Los algoritmos criptográficos se proporcionan en la JCE (Java Cryptography Extension o Extensión Criptográfica de Java) que, como su nombre lo dice, es la extensión de JCA (Java Cryptography Architecture o Arquitectura Criptográfica de Java).

Las tablas 17 y 18 muestran las clases de Java que se utilizan para firmar documentos.

Clase JCA 1.2 Función java.security.Signatura Firmado de datos y verificación firmas

java.security.KeyPairGenerator Generar pares de claves (pública y privada) para un algoritmo

java.security.KeyFactory Convertir claves de formato criptográfico a especificaciones de claves y viceversa

java.security.certificate.CertificateFactory Crear certificados de clave pública y listas de revocación(CRLs)

java.security.KeyStore Crear y gestionar un almacén de claves (keystore)

java.security.SecureRandom Generar números aleatorios o pseudo aleatorios

Tabla 17. Clases JCA

Clase JCE 1.2 Función

java.crypto.Cipher Proporciona encriptación y desencriptación

java.crypto.KeyAgreement Proporciona un protocolo de intercambio de claves

java.crypto.KeyGenerator Proporciona un generador de claves simétricas

java.crypto.SecretKeyFactory Representa un almacén de claves secretas

Tabla 18. Clases JCE

El código que se utiliza cuando se quiere realizar la firma se muestra en la tabla 19. class GenSig { public static void main(String[] args) { /* Generate a DSA signature */ if (args.length != 1) { System.out.println("Usage: GenSig nameOfFileToSign"); } else try{ /* Generate a key pair */ KeyPairGenerator keyGen = KeyPairGenerator.getInstance("DSA", "SUN"); SecureRandom random = SecureRandom.getInstance("SHA1PRNG", "SUN"); keyGen.initialize(1024, random); KeyPair pair = keyGen.generateKeyPair(); PrivateKey priv = pair.getPrivate(); PublicKey pub = pair.getPublic(); /* Create a Signature object and initialize it with the private key */ Signature dsa = Signature.getInstance("SHA1withDSA", "SUN"); dsa.initSign(priv);


54

/* Update and sign the data */ FileInputStream fis = new FileInputStream(args[0]); BufferedInputStream bufin = new BufferedInputStream(fis); byte[] buffer = new byte[1024]; int len; while (bufin.available() != 0) { len = bufin.read(buffer); dsa.update(buffer, 0, len); }; bufin.close(); /* Now that all the data to be signed has been read in, generate a signature for it */ byte[] realSig = dsa.sign(); /* Save the signature in a file */ FileOutputStream sigfos = new FileOutputStream("sig"); sigfos.write(realSig); sigfos.close(); /* Save the public key in a file */ byte[] key = pub.getEncoded(); FileOutputStream keyfos = new FileOutputStream("suepk"); keyfos.write(key); keyfos.close(); } catch (Exception e) { System.err.println("Caught exception " + e.toString()); } }; }

Tabla 19. Código Firma Digital SecureRandom es una fuente aleatoria que genera dos números Sha1PRNG.

KeyPairGenerator es una clase que genera una pareja de claves y las almacena en los objetos PrivateKey y PublicKey. Una vez que se tienen las claves pública y privada se llama al archivo que va a ser firmado para hacer un resumen del mismo con el algoritmo SHA-1.

Ya que se obtuvo la firma esta se almacena para enviarla junto con la clave pública. La tabla 20 muestra las claves pública y privada que se generan con la ejecución de esta clase.


55

Clave Privada: Sun DSA Private Key Parameters: p: fd7f5381 1d751229 52df4a9c 2eece4e7 f611b752 3cef4400 c31e3f80 b6512669 455d4022 51fb593d 8d58fabf c5f5ba30 f6cb9b55 6cd7813b 801d346f f26660b7 6b9950a5 a49f9fe8 047b1022 c24fbba9 d7feb7c6 1bf83b57 e7c6a8a6 150f04fb 83f6d3c5 1ec30235 54135a16 9132f675 f3ae2b61 d72aeff2 2203199d d14801c7 q: 9760508f 15230bcc b292b982 a2eb840b f0581cf5 g: f7e1a085 d69b3dde cbbcab5c 36b857b9 7994afbb fa3aea82 f9574c0b 3d078267 5159578e bad4594f e6710710 8180b449 167123e8 4c281613 b7cf0932 8cc8a6e1 3c167a8b 547c8d28 e0a3ae1e 2bb3a675 916ea37f 0bfa2135 62f1fb62 7a01243b cca4f1be a8519089 a883dfe1 5ae59f06 928b665e 807b5525 64014c3b fecf492a x: 482de65a 4f2e04d3 892a08f3 e64835e9 5ef36cb6 Clave Pública: Sun DSA Public Key Parameters: p: fd7f5381 1d751229 52df4a9c 2eece4e7 f611b752 3cef4400 c31e3f80 b6512669 455d4022 51fb593d 8d58fabf c5f5ba30 f6cb9b55 6cd7813b 801d346f f26660b7 6b9950a5 a49f9fe8 047b1022 c24fbba9 d7feb7c6 1bf83b57 e7c6a8a6 150f04fb 83f6d3c5 1ec30235 54135a16 9132f675 f3ae2b61 d72aeff2 2203199d d14801c7 q: 9760508f 15230bcc b292b982 a2eb840b f0581cf5 g: f7e1a085 d69b3dde cbbcab5c 36b857b9 7994afbb fa3aea82 f9574c0b 3d078267 5159578e bad4594f e6710710 8180b449 167123e8 4c281613 b7cf0932 8cc8a6e1 3c167a8b 547c8d28 e0a3ae1e 2bb3a675 916ea37f 0bfa2135 62f1fb62 7a01243b cca4f1be a8519089 a883dfe1 5ae59f06 928b665e 807b5525 64014c3b fecf492a y: 47dd09fb 40304866 cbcc24f6 13084bc1 ad6d4bf6 350b77b9 b0ab0f3f ec755278 cf456754 b8633b56 79fdf42a cbc9dd6c f207d6b1 b3dc7fb1 bc499b41 d9cdf01d a40bb77b 1d79cfe4 c0d47351 a83baba6 2e17296c 923f6a72 99ff72c2 43eb71b3 22394efa 0364f31f 0c9e3169 97df93d8 4d099df1 55b93411 f3575b18 8f906b26

Tabla 20. Claves pública y privada utilizadas para la firma digital. 3.5 Emitir Recibo El recibo de pago se genera una vez que la transacción ha concluido, utilizando los datos que el usuario ingresa dentro de la página de pago, es decir, su número de boleta, la clave del servicio y la cantidad del servicio que pagó. Dentro de las clases que se tienen en el sistema se programaron consultas que envían estos datos para compararlos con los existentes dentro de la BD para verificar que son correctos, de esta manera son almacenados y posteriormente ingresados al recibo. A través del manejo de sesiones se pueden recuperar los datos desde la pantalla de inicio para tener un seguimiento del alumno que realiza la operación y al emitir el comprobante se vean reflejados sus datos personales como son: nombre completo, dirección, grupo, turno, número de boleta.


56

El formato de pago se muestra en la figura 31.

Figura 31. Recibo de Pago

El código que guarda previamente los datos que serán impresos se encuentran en las clases DAO. En la tabla 21 se muestra dicho código. public AlumnoVO getListaAlumno(int NIP) throws DAOException { List listaAlumno = new ArrayList(); AlumnoVO alumno = null; try { ResultSet resultados = stmt.executeQuery("select * from alumno where NIP="+NIP+""); while ( resultados.next() ) { alumno = new AlumnoVO(); alumno.setNoBoleta(resultados.getInt("noBoleta")); alumno.setNombre(resultados.getString("Nombre")); alumno.setApellidoPaterno(resultados.getString("ApellidoPaterno")); alumno.setApellidoMaterno(resultados.getString("ApellidoMaterno")); alumno.setSemestre(resultados.getString("Semestre")); alumno.setGrupo(resultados.getString("Grupo")); alumno.setTurno(resultados.getString("Turno")); alumno.setDireccion(resultados.getString("Direccion")); alumno.setColonia(resultados.getString("Colonia")); alumno.setMunicipio(resultados.getString("Municipio")); alumno.setCP(resultados.getString("CP")); alumno.setSaldo(resultados.getFloat("saldo")); listaAlumno.add( alumno ); } } catch (SQLException e) {throw new DAOException("Error al realizar la consulta de alumno"); }

alumno.setLista2(listaAlumno); return alumno; }

Tabla 21. Metodo de la clase DAO para obtener los datos del alumno.


57

Posteriormente con la sentencia session.setAttribute("alumno",alumnoVO); se indica que el dato esta almacenado por si se requiere recuperar en alguna clase posterior o en la JSP asignada en este caso en el lugar donde se emite el recibo. Para imprimir el recibo se agrego un botón en la página donde se muestra que se realizo el pago de los servicios. Para lograr la impresión se utilizó la función que se muestra en la tabla 22. function printPage() { if (confirm("¿Imprimir Recibo?")) { window.print(); } }

Tabla 22. Función imprimir


58

4. 4.

PRUEBAS AL SISTEMA Las pruebas que se llevaron acabo para garantizar que el sistema funciona correctamente se describen a continuación. Acceso al Sistema La pantalla inicial del Sistema de Monedero Virtual para Pagos Escolares, presenta dos opciones: Administrador y Alumno, los cuales indican el tipo de usuarios que pueden ingresar. En la figura 32 se muestra la página de inicio.

Figura 32. Página de Inicio

Para garantizar que sólo los usuarios válidos en el sistema hagan uso de éste, se tiene un filtro de autenticación donde se válida la identidad el usuario en el reino de kerberos.pagos.com. Los usuarios que inicialmente se registraron en el sistema son:

Usuario Tipo Verenice AdministradorFernando Personal Pamela Alumno

Tabla 23. Nombre y tipo de usuario

Dentro de la opción Administrador los datos que se piden son RFC, nombre y contraseña. La Figura 33 muestra la página de logeo para un Administrador.


59

Figura 33. Página de Inicio: Administrador

Si introducimos el nombre o contraseña que no pertenezcan alguno de los registros mostrados en la tabla 23 se muestra en pantalla el mensaje de la figura 34, debido a que no es un usuario válido.

Figura 34. Mensaje de error: Usuario no válido.


60

Otro aspecto que se puede presentar es que Pamela inicie sesión desde una computadora, posteriormente otra persona quiere entrar al sistema con los datos de Pamela, como la primera sesión esta activa se muestra en pantalla un mensaje de error que indica que Pamela ya ha iniciado una sesión. Ocurre de la misma forma para un Administrador. En la figura 35 se muestra el mensaje de error para una sesión ya iniciada.

Figura 35. Error Sesión iniciada Si la sesión no ha sido abierta y los datos que se introducen son correctos la página que se muestra a continuación se encuentra en la Figura 36.

Figura 36. Menú Administrador


61

El Administrador es el único que puede realizar modificaciones en los registros de los alumnos y/o del personal administrativo. Si se elige la opción Alumnos el administrador puede dar de alta un nuevo alumno, eliminar un registro o modificar algún dato de un alumno que ya esta registrado. Las figuras 37, 39, 40 muestran las páginas para cada una de las opciones.

Figura 37. Dar de alta un alumno

Jonatan es un alumno que no está registrado en la base de datos, por lo que se ingresan todos sus datos personales, Apellido Paterno, Apellido Materno, Dirección, Colonia, Código Postal, etc.


62

Si no existe ningún registro anterior del alumno Jonatan la pantalla muestra que la operación fue exitosa. En la figura 38 se muestra la pantalla de éxito para dar de alta un nuevo Alumno.

Figura 38. Alumno registrado satisfactoriamente

Para eliminar un registro existente se debe ingresar el nombre de usuario y el número de boleta, en el caso de un alumno, o el RFC cuando se trata de un Administrador. Usamos el número de boleta 2007640120 perteneciente a Jonatan y el nombre de usuario con el que fue registrado “jonis”.

Figura 39. Eliminar un Alumno


63

Si el alumno se elimina correctamente se envía un mensaje de que el alumno fue eliminado (Figura 40).

Figura 40. Alumno Eliminado

Pamela es un registro que se encuentra almacenado en la BD y se realizó una modificación en su Apellido Paterno, para ello se ingreso su número de boleta, el campo que se modifico y el nuevo Apellido Paterno por el que se va a reemplazar el registro anterior (Figura 41).

Figura 41. Modificación de Alumnos


64

De la misma forma que en la figura 40 el mensaje que se muestra es referente a la modificación realizada. Si el Administrador elige la opción de Abono el sistema pide que se ingresen los datos del alumno, número de boleta y la cantidad a abonar (Figura 42).

Figura 42. Abono de dinero

Si el abono se realiza de manera adecuada el mensaje de éxito es similar al de la figura 40 cambiando la leyenda indicando que el Abono fue realizado y el nombre del alumno que recibió el abono. Para las otras opciones de Servicio y Personal el proceso es el mismo únicamente cambian los datos que deben ser introducidos, por ejemplo, para dar de alta un servicio se debe ingresar la clave de servicio, su descripción, el precio y el departamento al que pertenece dicho servicio. Un pago se realiza una vez que se autentifica al alumno, mostrando la página JSP de la figura 43, donde se observa una tabla con el saldo actual de dicho alumno y una lista de los servicios puede pagar. Para realizar este pago sólo es necesario elegir la clave e introducir la cantidad de este servicio que se quiere pagar.


65

Figura 43. Saldo del Alumno

Utilizando al mismo usuario (Pamela) para ingresar al sistema se tecleo el número de boleta, nombre de usuario y contraseña, como los datos están correctos se puede visualizar en la Figura 43 que su saldo es de $102.00. Ahora los servicios que se pueden pagar se encuentran en la tabla mostrada en la página de pago (Figura 44).

Figura 44. Pago de Servicios


66

Una vez que se eligió la cantidad del servicio que se pagó y la clave, se emite un recibo que contiene la opción para imprimirse. Este recibo contiene la información del alumno que realizo el pago y los datos del servicio que seleccionó (Figura 45).

Figura 45. Pago Realizado

La cantidad que se va a disminuir al saldo actual es de $30.00 por lo que si queremos verificar dicho descuento se puede oprimir el botón de MAS PAGOS para regresar a la página anterior que contiene esta información, observando que el saldo actual ahora es de $72.00 (Figura 46).

Figura 46. Saldo después del pago


67

CONCLUSIONES

El Sistema de Monedero Virtual para Pagos Escolares es un sistema que facilitará la realización de un pago dentro de la UPIITA, ya que un alumno puede realizar dicho pago desde la red de Internet. Las transacciones que se llevan a cabo son seguras debido a que se hace una autenticación de usuarios por medio de Kerberos, lo que permite que ingresen al sistema sólo los usuarios validados por dicho servidor y mantiene los password seguros ya que no viajan por la red. Las interfaces de usuario para administrar y acceder al sistema son sencillas, haciendo el uso del Sistema de Monedero Virtual para Pagos Escolares un sistema de fácil manejo. El uso de Struts para manejar el patrón MVC permite que el Sistema de Monedero Virtual para Pagos Escolares pueda ser adaptado a cualquier institución educativa que requiera el pago de servicios. El uso de MySQL realmente ayuda a tener un mayor cuidado de las operaciones que se hagan dentro de las tablas que contienen los datos, debido a que en su versión 5.0 es muy amigable y tiene incorporadas muchas aplicaciones que evitan que el programador se preocupe por esos detalles, como son el garantizar la integridad de los datos o que las operaciones se lleven acabo en su totalidad. El uso de MyEclipse ayudó a que se implementaran los Struts de manera sencilla gracias a las librerías que contiene este plugin, haciendo que la programación este más organizada. Se puede considerar que los objetivos que se plantearon al inicio se llevaron acabo gracias al manejo y aprendizaje del lenguaje de programación java.


68

TRABAJOS FUTUROS

El Sistema de Monedero Virtual para Pagos Escolares fue realizado mediante la arquitectura MVC y, por lo tanto, puede adaptarse fácilmente a las necesidades que surjan, dentro de la UPIITA.

Extender el sistema: Adaptar el sistema para ser utilizado por más escuelas del Instituto Politécnico Nacional u otras instituciones, además de incluir modulo para que el personal administrativo pueda realizar pagos.

Extender el tipo de pagos: Permitir que se realice el pago de inscripciones, títulos, etc.

Uso de tarjetas de crédito: Además del sistema de prepago, utilizar tarjetas de crédito con transferencia directa al banco.

Incorporar el sistema: Acoplar el Sistema de Monedero Virtual para Pagos Escolares al sistema SIGUE, para transferencia de datos de los alumnos y personal administrativo.


69

REFERENCIAS

[1] es.wikipedia.org/wiki/Modelo-Vista-Controlador [2] en.wikipedia.org/wiki/Model-view-controller [3] http://carlos-serrano-sanchez.blogspot.com/2006/10/modelo-mvc.html [4] Revista: “Solo Programadores” Año XI. 2ª Época No. 126. [5] http://enciclopedia.us.es/index.php/Lenguaje_de_programaci%C3%B3n [6] Fundamentos de Bases de Datos. Quinta Edición. Autores: Silberschatz, Korth, Sudarshan. Pag. 2 [7] Fundamentos de Bases de Datos. Quinta Edición. Autores: Silberschatz, Korth, Sudarshan. Pag. 17 [8] Cryptography and Network Security. 3ª Edition. Autor: William Stallings [9] http://www.pki.gov.ar/ [10] http://web.mit.edu/kerberos [11] http://es.wikipedia.org/wiki/X.509 [12] Algoritmos http://www.uv.es/~sto/cursos/seguridad.java/html/sjava-12.html [13] http://es.wikipedia.org/wiki/Tomcat [14] http://www.iec.csic.es/criptonomicon/ssl.html

Ingeniero en Telemática

Documents

Transcript of Ingeniero en Telemática