1. Resumen Esta propuesta de estudio da una solución a la problemática que se presenta en la UPIITA en la prestación de los servicios a su comunidad, tales como: los servicios de apartado y préstamo de bibliografía, recopilación de sugerencias bibliográficas, estadísticas de uso de libros y revistas, inscripciones a ETS, a un nuevo ciclo escolar, consulta de boletas de calificación en línea, entre otros. Así mismo aborda la problemática de la entrega oportuna de información a los diversos grupos de la comunidad: Alumnos, Profesores y Administrativos. La solución que proporciona la propuesta “Servicios Integrales de Información” consiste en: un Portal Web que integra los servicios de los diversos departamentos de la UPIITA. El portal esta soportado por una arquitectura de software que parte del hecho de que la información común a todos los departamentos debe de estar “concentrado”, es decir, estar accesible a cualquier ente de la comunidad, de tal forma que se reduzca la redundancia de información que se produce en un esquema donde cada ente genera y administra su información de manera aislada a los demás miembros de la comunidad. Sin embrago, cada departamento puede administrar su propia información, pero al seguir un esquema común de almacenaje y gestión de los datos, puede ser accedida por otros sistemas que así lo demanden. Para poder proporcionar los servicios a la comunidad mediante un Portal Web, se requiere de un esquema de autenticación de usuarios de acuerdo a su perfil: Alumno, Profesor o Administrativo. Además de la arquitectura planteada para soportar los servicios a los usuarios, se incluye un esquema de gestión de documentos, el cual consiste en controlar el envío de documentos entre miembros de la comunidad firmados electrónicamente, agilizando así el proceso de entrega y/o respuesta de oficios, memorando, solicitudes, entre otros. Palabras clave: Sistemas de información, certificado, firma digital.

2. Introducción La Unidad Profesional Interdisciplinaria en Ingenierías y Tecnologías Avanzadas requiere manejar información relacionada con procesos administrativos, docentes y académicos. Para ello requiere seguir un gran número de procedimientos proporcionados por autoridades del Instituto, en los cuáles se indica lo que se debe de hacer en cada trámite o servicio. Los procesos son muy complejos y tienden con facilidad al desorden y a la redundancia de información, esto es debido a que los departamentos cuentan con sistemas independientes que en algunos casos no son compatibles. Un ejemplo de esto es el departamento de control escolar que cuenta con dos bases de datos las cuales contienen la misma información de los alumnos y se tiene que capturar la información dos veces. Actualmente cada uno de los departamentos maneja su información ya sea de manera manual o electrónica, lo que provoca un mal manejo de la misma y un retraso en los procedimientos. Al no contar con mecanismos apropiados para distribuir la información a tiempo (mensajería ó correspondencia electrónica, etc.), en muchos casos ya no es vigente cuando llega al destinatario. Por lo que se requiere de un servicio de distribución de mensajes y oficios dentro de la unidad que sea adecuado a las necesidades de tiempo, de entrega y confidencialidad Por ejemplo; en control escolar cuando se solicita una constancia de servicio social el trámite se hace tedioso debido a que los alumnos tienen que ir a pedir información o comprobantes a otros departamentos; en este caso al departamento de titulación, el cual debe comprobar que el alumno tenga como mínimo el 70% de las materias acreditadas de la carrera y que este inscrito en el semestre que la solicita, ya que estos comprobantes tardan en realizarse un promedio de una semana, el tramite final se retrasa aun más por que la respuesta de la solicitud tarda una semana más en realizarse. Otro ejemplo es cuando hay que entregar un documento a una o varias personas que laboran en otro departamento, pues se tienen que estar buscando para que los firmen, sin mencionar que en muchas ocasiones se encuentran ocupados y no están dispuestos a atender, lo que ocasiona un mal uso del tiempo y una molestia a los usuarios. Esencialmente las secretarias y/o alumnos son los que se encargan de hacer llegar los documentos a los destinatarios, lo cual hace que sea un medio no seguro ni confidencial. De acuerdo a lo anterior, se propone un sistema que de solución a la gran mayoría de problemas:

• Entrega oportuna de documentos. • Confidencialidad de los documentos. • Duplicidad de trabajo. • Redundancia de información.

Permitiendo que se desarrollen de manera sencilla, segura, eficiente, haciendo uso adecuado de la información y asegurando la integridad de la misma. 3. Métodos experimentales La propuesta de estudio “Servicios Integrales de Información” se compone de dos módulos: Estructura y gestión de la información y autenticación de usuarios y gestión segura de documentos. • Estructura y gestión de la información. Este módulo aplica el patrón de arquitectura

Modelo Vista Controlador para separar la vista que los usuarios tienen del sistema de los procesos internos requeridos para la manipulación de la información, así como de los datos. En la figura 1, se observa el esquema general de este módulo, en el cual la información se estructura en bases de datos y en servicios de directorios. Las bases de datos contienen la información que tiene un comportamiento dinámico en el sistema y los servicios de directorios contienen la información estática, es decir, aquella que no sufre cambios o que los cambios son poco frecuentes.

Figura 1. Esquema general del sistema • Autenticación de usuarios y gestión segura de documentos. Este módulo permite la

autentificación de usuarios mediante la implementación de Kerberos, así como el uso de documentos electrónicos protegidos mediante firma digital para garantizar la integridad, autenticación y no repudio. Así mismo se emplea una infraestructura que proporciona los mecanismos para mantener la seguridad en la creación, asignación y manejo de la información. Para reducir la carga del sistema se propuso formar subredes lógicas como

el esquema que se muestra en la figura 2. Cada subred representa un reino para la autenticación de kerberos, por lo que también se implemento la autenticación entre reinos, para que desde cualquier subred los usuarios puedan acceder al sistema.

Alumnos A

Figura 2. Esquema de seguridad en subredes En la sección 3.1 se describe el módulo de estructura y gestión de la información y en la sección 3.2 se describe el módulo autenticación de usuarios y gestión segura de documentos. Cada una de las secciones muestra las fases efectuaron para desarrollar la solución propuesta. 3. 1 Estructura y gestión de la información Este módulo se encarga de estructurar la información recopilada en los siguientes departamentos: • Control Escolar • Biblioteca • DOPE • Cómputo y Comunicaciones • DIyTA

Para la gestión de la información se emplea un Portal WEB que permite acceder y mantener actualizada la información. Cabe aclarar que en esta propuesta de estudio únicamente se implementa en el portal WEB la sección correspondiente al departamento de Control Escolar y Biblioteca. A continuación de describen las fases realizadas:

Profesores

Personal Administrativo

A F

A

IPN

Autentificación InterDominio

3.1.1 Fase de recopilación y análisis de requerimientos Esta fase consistió en recopilar y analizar los requerimientos de cada uno de los procesos y servicios que proporciona los departamentos de la UPIITA citados anteriormente. La recopilación de la información se hizo a través de entrevistas a la comunidad de la unidad y revisando manuales de procedimientos. Los requerimientos se muestran en diagramas de casos de uso del UML (Unified Modeling Language, por sus siglas en ingles.). Para cada uno de los departamentos se muestra el diagrama de casos de uso general, indicando los actores que intervienen y los roles que desempeñan. Además se indica cuales casos de uso son explícitos o implícitos. A continuación se describe cada uno de los departamentos. A. Departamento de Control Escolar En la figura 3 se muestra en el caso de uso general del departamento de Control Escolar. En este diagrama se puede observar como interactúan los actores con los casos de uso. Descripción de actores: actCeControlEscolar: Es el encargado de interactuar con el actor Alumno y los departamentos de.- DOPE, Vinculación Académica, Extensión de Apoyo a Estudiantes, Subdirección Técnica, Dirección, Cómputo y Biblioteca.

Sus principales funciones son:

• Actas ópticas • Altas y bajas de alumnos • Emisión de boletas y constancias • Inscripciones y reinscripciones • Recursamientos • Manejo de expedientes • Inscripciones a ETS • Comisión de situación escolar • Elaboración de estadísticas

ActUsuario: Este actor interactúa directamente con el actor Control Escolar para realizar diferentes trámites, los cuales son:

• Inscripciones y reinscripciones • Inscripción a ETS • Recursamientos • Petición de boletas y constancias

Descripción general Los casos de uso se modelaron seccionándolos de acuerdo a las actividades que se realizan, partiendo de lo más general a lo más específico. Tal es el caso del escenario Inscripciones y Reinscripciones el cual fue dividido a su vez en los siguientes sub-escenarios.

• Inscripción de alumnos de nuevo ingreso • Reinscripción de alumnos dentro de reglamento • Reinscripción de alumnos de cambio de carrera • Reinscripción de alumnos de cambio de turno o grupo • Reinscripción de alumnos de sexto semestre • Reinscripción de alumnos que reingresan por baja temporal

En los cuales se detalla de manera más profunda los casos de uso involucrados en el escenario de Inscripciones y Reinscripciones. Durante el análisis de éstos se identificaron dos tipos de actores, primarios y secundarios, los cuales son Control Escolar y Alumno respectivamente.

Casos de uso explícitos • Actas ópticas • Altas y bajas de alumnos • Emisión de boletas y constancias • Inscripciones y reinscripciones • Recursamientos • Manejo de expedientes • Inscripciones a ETS • Comisión de situación escolar • Estadísticas

Casos de uso implícitos • Acceso al sistema • Creación de expediente • Creación de usuario

B. Departamento de Biblioteca

Los casos de uso que modelan los procesos y servicios del departamento de biblioteca se muestran en la figura 4.

Descripción de Actores actBibServiciosPúblico: Se encarga de Publicar el material, Registrar el usuario, Prestar material, Prestar Servicios, Dar procedimiento ala reposición de material.

actUsuario: Representa a todas aquellas personas que puedan adquirir servicios en la Biblioteca, Debe de conocer el reglamento interno o por lo menos poder consultarlo en la red, para cualquier aclaración o duda de acerca de un procedimiento, también debe de poder consultar el material disponible como el numero de ejemplares. actBibEncargadoBiblioteca: Da mayor seguimiento ala reposición de material (Extraviado ó Dañado), Registrar la llegada un material (Nuevo ó Reposición) y Realización de estadísticas.

actBibDesarrolloColecciones: Revisa las peticiones Bibliográficas, solicitar la adquisición de libros.

dcuCeActasOpticas

dcuCeEmisionBoletasConstancias

dcuCeInscripcionesReinscripciones

dcuCeManejoExpedientes

dcuCeRecursamiento

actCeControlEscolar

actUsuario

(from dcuUpiita)

dcuCeComisionSituacionEscolar

dcuCeInscripcionAlumnosEts

dcuCeEstadisticas

dcuCeCreacionUsuario

dcuCeCreacionExpedientes

dcuCeAltasAlumnos

dcuCeBajasAlumnos

Figura 3. Diagrama CU general del departamento de Control Escolar

actBibProcesosTécnicos: Recibir, Clasificar y Catalogar el material, Registrar en el sistema para impresión de fichas y etiquetas.

Descripción General Los procesos que se llevan acabo en la biblioteca se pueden separar en:

• Referente al Usuario • Referente al material de la biblioteca • Referente al servicio • Referente a la adquisición de nuevo material

Los usuarios son los alumnos inscritos, así como el personal docente y administrativo. Esta división de usuarios permite restringir el acceso al sistema. Por ejemplo, si se trata de un alumno solo se dará acceso a los servicios de biblioteca si y solo si este inscrito, así como el personal docente y administrativo deberá estar en la nomina del semestre en curso.

Se entenderá por material de biblioteca:

• Libros. o Acervo de Consulta.- solo se prestan para sala de biblioteca y debe de ser

entregado ese mismo día. o Acervo General.- se divide en dos por razones internas:

Préstamo a Domicilio.- Estos libros son los que se pueden llevar ciertos días a casa, pero esto depende del tipo del tipo de usuario al que se pertenezca.

Reserva.- Se debe de tener dos ejemplares de cada adquisición, uno para el turno matutino y otro para el turno vespertino y los sobrantes son para Préstamo a Domicilio. Los de reserva son libros que se tienen que entregar ese mismo día.

• Tesis • Publicaciones periódicas • Videos y diskettes 3.5”. • Audio-casetes • Revistas • Periódicos.

Los usuarios están clasificados en tipos:

-Tipo A: Alumnos -Tipo B: Personal administrativo -Tipo C: Personal docente -Tipo D: Externos

actBibEncargadoDesarrolloCole...

actBibProcesosTecnicos

dcuBibPublicacionMaterial

dcuBibPrestamoMaterial

dcuBibReponerMaterial

dcuBibRealizacionEstadisticas

dcuBibDesarrolloColecciones

dcuBibProcesosTecnicos

Registro de recepcion de materialactBibEncargadoBiblioteca

Checar el reglamentoactUsuario

(from dcuUpiita)

Registrar tipo de usuarioactBibServicioPublico

Figura 4. Diagrama CU general del departamento de Biblioteca

Casos de uso explícitos: • dcuBibPublicaciónMaterial • dcuBibPrestamoMaterial • dcuBibChecar el reglamento • cduBibReponerMaterial

Casos de uso implícitos: • dcuBibRegistrar tipo de usuario

C. Departamento de Organización del Proceso de Enseñanza En la figura 5 se muestra en el caso de uso general del departamento. En este diagrama se puede observar como interactúan los actores con los casos de uso. Descripción de Actores actDopeEncargado: Es el jefe del departamento, en donde tiene la responsabilidad de planear la estructura referente a la creación, organización y distribución de grupos, también elabora los horarios de clase; en salón y laboratorios, asignando los profesores comprometidos en dicho horario.

Otra de sus funciones es la entrevistar, y programar exámenes de oposición para profesores que deseen laborar en la Unidad Profesional Interdisciplinaria de Ingeniería en Tecnologías Avanzadas (UPIITA). Es responsabilidad de él, la de detectar necesidades académicas (asignaturas en las que no hay profesor) para presentarlas en las Direcciones Generales del Instituto Politécnico Nacional competentes, con el fin comprobar y realizar las contrataciones de personal docente. actDopeSecretaria: Son funciones principales de la secretaria: crear las circulares 20 para cada profesor contratado, la elaboración de constancias de carga académica de cada profesor de la UPIITA, la preparación de constancias para los profesores que fungen como sinodales en los exámenes de oposición, planear los terceros exámenes departamentales; así como también los exámenes extraordinarios y a titulo de suficiencia, elaboración de oficios, memos electrónicos, entre otras cuestiones.

Cabe mencionar que si por alguna razón alguno de los actores no pudiera llevar a cabo sus responsabilidades de trabajo, el otro actor tendría que realizarlas.

Descripción general En la figura 6, en la que se muestra un panorama general de los procesos y servicios que lleva acabo y proporciona el departamento. La mayoría de los casos de uso son de tipo explícitos, aunque también se tienen casos de uso implícitos. Se puede observar todas las funciones que son realizadas por el Departamento de Organización del Proceso de Enseñanza (DOPE) y los actores que las realizan. Cada periodo educativo el encargado comienza a hacer un análisis de la estructura académica para detectar necesidades de personal. La estructura académica involucra la programación de horarios, profesores, salones, laboratorios y grupos. En base a la estructura, se realiza el proceso de contratación de profesores que cubran las necesidades académicas. Cuando se encuentra bien definida la estructura, la secretaria debe realizar circulares 20, cargas

académicas, registrar todos los documentos que realice en el cuaderno electrónico de registro. El encargado lleva el trámite de los dictámenes de categoría tanto para profesores base como de interinato.

dcuDopeCirculares20

dcuDopeCargasAcadémicas

dcuDopeCuadernoElectrónicoRegistro

dcuDopeEstructura

actDopeEncargado

actDopeSecretaria

dcuDopeReclutamientoProfesores

dcuDopeDictamenCategoria

usa

usa

usa

usa

Figura 5. Diagrama CU general del DOPE

Casos de uso explícitos

• dcuDopeCargasAcadémicas. • dcuDopeCirculares20. • dcuDopeCuadernoElectrónicoRegistro. • dcuDopeDictamenCategoría.

• dcuDopeEstructura. • dcuDopeReclutamientoProfesores.

Casos de uso implícitos.

• dcuDopeReclutamientoProfesores.

D. Departamento de Cómputo y Comunicaciones En la figura 6 se muestra en el caso de uso general del departamento de Cómputo y Comunicaciones. En este diagrama se puede observar como interactúan los actores con los casos de uso. Descripción de actores: actCcRecepción. Encargado de recibir las solicitudes de servicio como son: Préstamo de Salas, Equipo de Cómputo, Servicios de Impresión, etc. Además registra dichas solicitudes en una bitácora y solicita identificación del usuario.

actUsuario. Es la persona que solicita algún servicio al departamento de cómputo. Estos pueden ser: Préstamo de Salas, de Equipo de Cómputo, solicitud de soporte técnico, Servicios de Impresión, etc.

actCcEncargado. Es el Jefe del Departamento de Cómputo y Comunicaciones, el cual tiene la función de recibir ciertas peticiones de trabajo y delegárselas a su personal, así como también recibir inventarios de equipo de cómputo recién adquirido por la UPIITA y distribuirlo a los distintos departamentos de la misma. Mantiene comunicación los diferentes departamentos de la UPIITA mediante una serie de oficios.

actCcEncargadoMantenimiento. Es la persona o conjunto de personas las cuales proporcionan soporte técnico a los usuarios que lo soliciten. También lleva el control de la lista de solicitudes de soporte técnico correspondientes.

actCcEncargadoWeb. Persona encargada de administrar las publicaciones Web por publicar o ya publicadas.

actCcSecretaria. Es la secretaria del Jefe del DCyC, la cual tiene la función de enviar respuesta a los oficios recibidos por el Jefe del DCyC y archivarlos.

actProfesor. Es el personal docente que solicita algún servicio al departamento de cómputo. Estos pueden ser: Préstamo de Salas, de Equipo de Cómputo, solicitud de soporte técnico, Servicios de Impresión, etc.

actCcDirector. Se refiere al director de la UPIITA, el responde solicitudes de autorización por parte del Jefe del DCyC.

Descripción general Este departamento ofrece diversos servicios a la comunidad de la unidad, como son: préstamo de computadoras, proyectores, salas para exposiciones, servicio de impresiones. También se encargan del mantenimiento y soporte de equipo de cómputo de la unidad. El usuario solicita algún servicio al departamento donde el encargado va a recibir las solicitudes de servicio de préstamo de servicios, registra las solicitudes en una base de datos, en donde se verifica si el alumno esta inscrito, si tiene sanciones, el jefe del departamento tiene la función de recibir ciertas peticiones de trabajo y delegárselas a su personal, para ello el encargado recibe oficios de solicitudes de trabajo, también puede realizar una solicitud de autorización al departamento de dirección, si hay prioridades pendientes, se hace una petición de servicio, se determina a que departamento tiene la prioridad para destinarse el equipo. Casos de uso explícitos

• Cobro de impresiones • Destinar equipo a necesidades prioritarias • Entrega de equipo de cómputo • Envío respuesta solicitud • Formar petición de servicio • Generar orden de trabajo a técnicos • Préstamo de equipo a alumnos • Préstamo de equipo de salas a profesores • Recepción de oficios de solicitudes de trabajo de los departamentos • Servicio de impresión y entrega de equipo • Servicio de impresión para préstamo • Solicitud de autorización del director • Soporte técnico • Solicitud para publicación de bolsa de trabajo

Casos de uso implícitos

• Aplicar sanción al usuario • Verificar alumno inscrito

dcuCcCobroImpresiones

dcuCcDestinarEquipoNecesidadesPrioritorias

dcuCcEntregaEquipoComputo

dcuCcEntregaPrestamoEquipoAudioVisual

dcuCcEnv ioRespuestaOf icioSolicitud

dcuCcFormarPeticionServ icio

dcuCcGenerarOrdenTrabajoTecnicos

dcuCcPrestamoEquipoAlumnos

dcuCcPrestamoEquipoSalasProf esores

dcuCcRecepcionOf iciosSolicitudesTrabajoDeptos

dcuCcServ icioImpresiónEntregaEquipo

dcuCcServ icioImpresiónPrestamo

dcuCcSolicitudAutorizaciónDirector

dcuCcSoporteTecnico

dcuCcVerif icarAlumnoInscrito

dcuCcSolicitudPublicacionBolsaTrabajo

actCcRecepción

dcuCcAplicarSanciónUsuario

actCcEncargado

actUsuario

(from dcuUpiita)

actCcSecretario

actCcEncargadoMantenimiento

actProf esor

(from dcuUpiita)

actDirDirector

(from dcuDir)

actCcEncargadoWeb

actTitSecretaria

(from dcuTit)

Figura 6. Diagrama CU general del departamento de Cómputo y Comunicaciones

E. Departamento de Ingenierías y Tecnologías Avanzadas - DIyTA Los casos de uso que modelan los procesos y servicios del DIyTA se muestran en la figura 7. Descripción de actores:

actUsuario. Es la persona que solicita algún servicio al DIyTA.

actDiytaEncargado. Es el Jefe del DIyTA, el cual tiene la función de recibir ciertas peticiones de las academias, laboratorios, así como aprobar esas peticiones. Además mantiene comunicación con los diferentes departamentos de la UPIITA mediante una serie de oficios. Descripción general El DIyTA, tiene la función de estar al pendiente de peticiones por parte de las academias, laboratorios, así como aprobar esas peticiones. Además mantiene comunicación con los diferentes departamentos de la UPIITA mediante una serie de oficios. Ahí se coordina la logística de proyectos terminales que es importante para los alumnos, se revisan los horarios, se verifica que los maestros cumplan con el plan de academia entre otras cosas. Dentro del DIyTA básicamente revisa el desempeño docente, en cuanto al cumplimiento de planes de estudio, ve que tan eficientes son, ahí se determina si se modifica ese plan o la actualización que se procede, además de verificar las actividades de cada profesor por que no todo el tiempo este dando clases y ese tiempo que le sobra se justifica, a eso se le llama descarga docente, se coordinan la logística de proyectos terminales, se da seguimiento a si algún alumno hace servicio social con un profesor de la escuela, se coordina este departamento con la DOPE para la revisión de horarios, para la cual DIyTA emite una opinión que es tomada en cuenta para la DOPE, se esta al tanto de peticiones por parte de las academias, laboratorios que tienen que ver que el mobiliario, material, equipo de trabajo de los laboratorios.

a c tD i y ta E n c a rg a d o

d c u D i y ta C re a c i o n D e sc a rg a Do c e n te s

d c u Di y taE l a b o ra ci o nO f i c i o d e C o m i si o n

d c u D i y ta M a n e j o O f i c i osR e c i b i d o s

d c u D i y ta S e gS e rv i ci o So c i a l P ro fe so re s

d c u D i y ta L o g i st i c a P ro ye c to sT e rm i n a l e s

d c u D i y ta S u p e rv i si o n P erso n a l D o c e n ted c u D i y ta R e v i si o n H o ra ri

o sE x a m e n e s

Figura 7. Diagrama CU general del DIyTA

3.1.2 Fase de diseño Esta fase consistió en diseñar los diagramas de clases en UML correspondientes a los casos de uso del departamento de Control Escolar y Biblioteca, ya que son los únicos departamentos que aparecen en el portal. Así mismo se diseño el modelo relacional de la base de datos que almacena la información de los departamentos. Diagrama de clases Las clases que se muestran en la figura 8 son de tipo general, es decir; son clases que son utilizadas en Control Escolar y Biblioteca. Estas clases permiten la gestión de la información relacionada a alumnos, profesores, administradores. Además administran los permisos de acceso, así como la lógica que se seguirá en los procedimientos de cada departamento. En los archivos dcControlEscolar y dcBiblioteca se encuentran las imágenes de los diagramas de clases del departamento de Control Escolar y Biblioteca respectivamente.

dcBib(from dcUPI...)

dcCe(from dcUPI...)

ComunidadAlumnoboleta : Stringgrupo : StringcreditoElectronico : Float

actualizarExpediente()actualizarCreditoElectronico()consultarCalificaciones()solicitarBoleta()solicitarConstancia()inscripcionEts()solicitarHorario()verProfesores()mostrarAlumno()solicitarInscripcionRecursamiento()

GrupoTrabajonombreGrupo : Stringintegrantes : String[]comunidad : Object

agregarIntegrante()el iminarIntegrante()buscarIntegrante()mostrarGrupoTrabajo()el iminarGpoTrabajo()

estaFormado

1..n

1..n

ComunidadProfesorrfc : string;categoria : string;tipoContrato : string;academia : string;grupo : Grupodocumento : Documento

enviarDocumento()crearDocumento()actualizarExpedienteProfesor()consultarHorarios()verProfesor()verProfesor()

estaFormado1..n 1..n

consulta

0..n

0..n

comunidadnombre : Stringapellidos : Stringsexo : StringfechaNacimiento : Datecurp : Stringpermisos : PermisosgrupoTrabajo : GrupoTrabajoclave : Stringdireccion : Stringtelefono : Intcp : StringestadoCivil : Stringestatura : Floatpeso : FloatcorreoElectronico : String

notificarClave()consultarDatosPersonales()modificarDatosPersonales()capturaClave()ingresarSistema()...

Permisoslectura : Booleanescritura : Boolean

obtenerpermisosPermisos()mostraPermisos()cambiarpermisos()

+1..1+1..1 tiene

Administradorcargo : String

crearHorario()crearGrupo()elaboraEstadisticas()realizarInscripcion()modificarPermisos()emitirConstancia()publicarActas()

+1..1

+1..n

asigna

Figura 8. Diagrama de clases comunes Base de Datos La figura 9 muestra el modelo relacional de la base de datos de Biblioteca. Cabe aclara que este diagrama contiene todas las entidades involucradas en la biblioteca, aunque algunas de esas entidades se alojan en un servicio de directorios y no propiamente en una base de datos. La razón de esto, es que en la base de datos únicamente se almacena la información que tiene un cambio dinámico, como lo es el escenario de préstamo y apartado de material. Y en el servicio de directorio se almacena la información que tiene un comportamiento estático o de poco cambio, como lo es el acervo del material y los datos de los usuarios. Al incluir todas las entidades el modelo de la figura 9, permite observar la interacción que tienen en el sistema. El diseño de la base de datos se realizó basándose en los casos de uso analizados para el departamento de biblioteca, involucrando a todas las entidades, para tener un panorama general de cómo será su interacción dentro del sistema. Los atributos de cada una de las entidades se obtuvieron de acuerdo al seguimiento de las actividades que realiza el departamento, tomando en cuenta los formatos que ya se tienen y los formularios que el departamento desea tener para llevar un mejor control de sus

actividades, así como toda la información proporcionada por sus manuales de procedimientos.

Figura 9. Modelo Entidad Relación del departamento de Biblioteca

En la figura 10 se muestra el modelo relacional de la base de datos que almacena la información del departamento de Control Escolar. En el modelo se pueden observar las entidades involucradas en el departamento. Cabe aclarar que en el modelo presentado se encuentran tanto las entidades creadas en el Servicio de directorios como en la Base de Datos.

Figura 10. Modelo Entidad Relacional del departamento de Control Escolar

3.1.3 Fase de implementación. Para llevar acabo esta fase, se analizó las herramientas que permiten implementar el MVC, sistemas gestores de bases de datos y servicios de directorios. El análisis partió de la idea de emplear herramientas de tipo código abierto “licencias libres”, con la finalidad de no ajustarse a un proveedor o a una plataforma se sistema operativo. En cuanto al manejador de bases de datos a emplear se analizaron los siguientes manejadores de bases de datos: MySQL. Postgres y Oracle (aunque no es de código abierto, pero opera en Windows y Linux). Se decidió trabajar con Oracle por la funcionalidad que proporciona, además de que en el IPN se pueden gestionar licencias educativas. En cuanto al servicio de directorios se opto por emplear OPENLDAP por ser de código abierto y por la estandarización que sigue en la creación y gestión de los árboles. Los directorios están optimizados para acceso en lectura, frente a las bases de datos convencionales, que se encuentran optimizadas para lectura y escritura. Los servicios de directorios al tener una estructura jerárquica agilizan las lectura pero no las escrituras por lo que están orientadas a almacenar la información de comportamiento estático. En cuanto a los lenguajes de programación y API´s que permiten la implementación del MVC, se analizarón JAVA, C++, Perl y PHP. Después del análisis efectuado considerando las API´s que proporcionan, se optó por tecnología JAVA entre la que destaca STRUTS, EJB, Servlets y JSP´s..

3.2 Autenticación de usuarios y gestión segura de documentos.

Este módulo consiste en controlar la autenticación de usuarios y envío seguro de documentos protegidos mediante firma digital. La finalidad de este módulo es: • Implementar un mecanismo que garantice que sólo los usuarios válidos ingresen al

sistema.

• Crear una infraestructura que permita la creación y distribución de llaves públicas de los usuarios.

• Implementar el mecanismo de protección y envío seguro de documentos.

• Elegir el medio más conveniente para almacenar la información.

• Generar acuses de recibo automáticos cuando se entregue un documento.

• Mantener un archivo histórico de los documentos enviados.

• Mantener un registro de las operaciones en el sistema para identificar anomalías.

• Desarrollar interfaces de usuario para administrar y acceder a los servicios.

A continuación de describen las fases realizadas para lograr la implementación de este módulo: 3.2.1. Fase de recopilación, análisis de requerimientos y diseño A continuación se describen los casos de uso que tiene el usuario, así como las consideraciones de implementación. A. Caso de uso de la Interfaz de la PKI. A fin de proveer una operación segura en la comunicación a través de documentos electrónicos mediante algoritmos de criptografía asimétrica, es necesario tener una infraestructura que permita administrar y distribuir las llaves públicas de forma ágil y con la confianza de que cada correlación de llave pública – usuario implica necesariamente la corroboración de la identidad de los usuarios con base en la comparecencia física y presentación de documentación oficial al momento de darse de alta en el sistema.

El diagrama de casos de uso que se muestra en la figura 11 ilustra cada uno de los casos de uso que ejecuta el Administrador al utilizar la interfaz de la PKI.

Figura 11. Casos de uso de la interfaz de la PKI En este caso el usuario es el Administrador de la PKI y tiene la posibilidad de realizar los casos de uso:

Ver CRL.- En la interfaz de la PKI podrá solicitar el contenido de la CRL, para mostrarlo en pantalla y revisar los números de serie de los certificados revocados.

Revocar certificado.- Podrá poner en estado de Revocado un certificado, previamente especificando a quién pertenece y qué tipo de usuario es.

Generar certificado.- Será capaz de crear un certificado a una persona que exista en el árbol de directorios. Será requisito el revisar los datos del usuario antes de la generación.

Reactivar certificado.- Si un usuario solicita la reactivación del certificado, el Administrador le pedirá su identificador para poner en estado de Vigente el certificado revocado anteriormente.

Ver certificado.- Se refiere a obtener el número de serie del certificado, que podrá ser de utilidad para buscarlo en la Lista de Revocación o para buscarlo y realizar alguna acción.

Los certificados de los alumnos deberán crearse al ingresar a primer semestre en la UPIITA, específicamente en el proceso de inscripción. Para el caso de personal administrativo y docente, el certificado se creará cuando ingrese a laborar en la institución y se le forme su expediente en el departamento de Recursos Humanos. Por el momento, los certificados se crean desde la interfaz de la PKI, accediendo a la información que existe en el sistema de directorios. A continuación se muestran los escenarios que ocurren en la interfaz de la PKI.

Generar certificado

• El administrador entra en sesión. Se establece la conexión con el árbol de directorios. Hace la petición de generar un certificado.

• Indicar al sistema el tipo de usuario al que se quiere generar el certificado (Alumno, Profesor o Administrativo).

• De acuerdo al tipo de usuario seleccionado, se pedirá un identificador (Boleta para Alumnos, CURP para otro tipo).

• Se realiza la conexión con el sistema de directorios. Si la conexión es exitosa, se realiza una búsqueda en el sistema de directorios por medio del identificador introducido. De lo contrario no se podrá continuar.

• Si se encuentra el identificador, se muestran los datos necesarios para la creación del certificado, en caso de que falte alguno, no se podrá realizar el proceso de creación.

• Se comprueba que el usuario no tenga ya un certificado.

• En caso de tenerlo, se verifica el estado (Revocado o Vigente) mediante una inspección en el archivo de registro. En el otro caso, se crea automáticamente.

• Si está Revocado, se ofrecen las opciones de Reactivación o Creación de uno nuevo.

• Si está Vigente, se tiene la opción de conservarlo, o revocarlo y crear otro automáticamente.

• Si el proceso de creación es exitoso, se registra en la bitácora y se actualizan los campos que corresponden a la llave, solicitud y certificado dentro del sistema de directorios.

Revocar certificado

• El administrador entra en sesión. Se establece la conexión con el árbol de directorios. Hace la petición de revocar un certificado.

• Indicar al sistema el tipo de usuario al que se quiere revocar el certificado (Alumno, Profesor o Administrativo).

• De acuerdo al tipo de usuario seleccionado, se pedirá un identificador (Boleta para Alumnos, CURP para otro tipo).

• Se realiza la conexión con el sistema de directorios. Si la conexión es exitosa, se realiza una búsqueda en el sistema de directorios por medio del identificador introducido. De lo contrario no se podrá continuar.

• Si se encuentra el identificador, se muestran los datos necesarios para comprobar la identidad de usuario del certificado, en caso de que falte alguno, no se podrá realizar el proceso.

• Se comprueba que el usuario tenga un certificado. En caso de no tenerlo, no se podrá continuar.

• Verificar el estado del certificado (Revocado o Vigente).

• Si está revocado, no se podrá seguir con el proceso.

• Si está vigente, se procede a la revocación automática.

• Se genera o actualiza la lista de revocación de certificados. Reactivar certificado

• El administrador entra en sesión. Se establece la conexión con el árbol de directorios. Hace la petición de reactivar un certificado.

• Indicar al sistema el tipo de usuario al que se quiere reactivar el certificado (Alumno, Profesor o Administrativo).

• De acuerdo al tipo de usuario seleccionado, se pedirá un identificador (Boleta para Alumnos, CURP para otro tipo).

• Se realiza la conexión con el sistema de directorios. Si la conexión es exitosa, se realiza una búsqueda en el sistema de directorios por medio del identificador introducido. De lo contrario no se podrá continuar.

• Si se encuentra el identificador, se muestran los datos necesarios para comprobar la identidad de usuario del certificado, en caso de que falte alguno, no se podrá realizar el proceso.

• Se comprueba que el usuario tenga un certificado. En caso de no tenerlo, no se podrá continuar.

• Verificar el estado del certificado (Revocado o Vigente).

• Si está Revocado, se procede a la reactivación automática, se actualizan los campos de certificados anteriores y certificado actual.

• Si está vigente, se detiene el proceso.

• Se actualiza la CRL. Ver CRL

• El administrador entra en sesión. Se establece la conexión con el árbol de directorios. Hace la petición de ver la Lista de Revocación de Certificados.

• Se busca el archivo que corresponde a la CRL. Si no existe, no habrá datos que mostrar. De lo contrario se abre y se muestra la información pertinente.

Ver certificado de usuario

• Podrá darse el caso de que un usuario necesite saber el estado de su certificado. Esta interfaz sólo permite saber qué número de serie tiene el certificado actual y cuáles son los certificados revocados que pudo tener.

• Indicar al sistema el tipo de usuario del que se quiere conocer el número de serial del certificado (Alumno, Profesor o Administrativo).

• De acuerdo al tipo de usuario seleccionado, se pedirá un identificador (Boleta para Alumnos, CURP para otro tipo).

• Se realiza la conexión con el sistema de directorios. Si la conexión es exitosa, se realiza una búsqueda en el sistema de directorios por medio del identificador introducido. De lo contrario no se podrá continuar.

• Se obtiene el certificado actual y los certificados anteriores.

• Si se obtienen resultados del procedimiento anterior, se muestra en una tabla.

• Se cierra la conexión con el sistema de directorios. Cadena de confianza Para el funcionamiento de la PKI y la verificación de certificados, se tiene un esquema de 3 certificados de Autoridades certificadoras que se muestran en la figura 12.

Figura 13. Cadena de confianza propuesta

Figura 12. Esquema de certificados expedidos mediante la cadena de confianza propuesta

En el diagrama se observa el vínculo que tiene cada certificado, es decir, fue expedido por la CA inmediata superior hasta llegar al ancla de confianza: Banco de México. El esquema de la cadena de confianza se muestra en la figura 13.

Banco de México

UPIITA

Entid ario finales ades usu

IPN

Usuario: BANXICO

Usuario: Usuario: IPN Emisor:

BANXICOFirmaCA: BANXICO

Emisor: BANXICOFirmaCA: BANXICO

UPIITAEmisor: IPN FirmaCA: BANXICO

Usuario: UsuarioEmisor: UPIITA

FirmaCA: BANXICO

. Caso de uso Gestión de Documentos. B

. Así como un edio de envío y recepción de documentos similar a un correo electrónico.

umentos lectrónicos en la interfaz del editor. Los casos de uso se muestran en la figura 14.

ministrar sus ocumentos mediante las siguientes acciones (de acuerdo a los casos de uso):

Para que el usuario pueda manipular sus propios documentos, es necesario una interfaz que le proporcione facilidades de creación, firmado, guardado y eliminaciónm Este punto se refiere a las acciones que puede realizar el usuario referente a doce Cualquier usuario registrado en el sistema tiene la capacidad de generar y add Editar documento o plantilla.- Se refiere a realizar la petición del servicio de edición de documento. Una vez hecho esto, se direcciona al editor en línea para generar un

ocumento.

•

d

Firmar, Guardar documento.- Una vez que el usuario genera un documento, lo puede guardar para realizar posteriormente un envío. Se le pedirá un nombre de archivo y se guaradrá en la rama del árbol que corresponda. Así mismo se puede

•

elegir el establecer un documento generado como una plantilla.

Borrar documento.- Al cargar un documento, se puede elegir la opción de eliminarlo de la loita de documentos.

Figura 14. Casos de uso correspondientes a la gestión de documentos Cargar Documento o Plantilla.- De la lista de documentos guardados de un usuario, éste

uede seleccionar uno de ellos y automáticamente se visualizará en el editor. p

Enviar Documento.- Una vez guardado un documento finalmente se firmará y se mostrará en pantalla la versión final para el envío. Se podrá seleccionar el destino del mismo. Revisar bandeja de entrada.- Se refiere a ver los documentos recibidos. Una vez que el usuario entre en sesión, automáticamente se visualizarán los documentos recibidos, con una verificación previa del certificado del emisor. Un usuario sólo podrá guardar documentos si tiene una llave privada. Los escenarios de la interfaz del editor que se refieren a la gestión de documentos se describen a continuación. Bandeja de entrada

• El usuario entra en sesión. Se realiza una conexión al sistema de directorios.

• Se hace una consulta para saber si es un usuario que tiene una secretaria asignada.

• Se buscan todos los documentos y se realiza la verificación de la cadena de confianza, así como el estado del certificado del emisor.

• Si resulta exitoso el procedimiento anterior, se envía el acuse de recibo para los documentos en los que no se haya hecho. Previamente se busca la llave privada del destinatario para firmar el acuse.

• Se verifica la integridad del documento mediante el certificado del emisor.

• Se realiza una división de documentos: los recibidos por la secretaria, los recibidos por otro usuario.

• Se muestran los documentos en su sitio correspondiente.

• Se termina la conexión con el sistema de directorios. Borrar documento o plantilla

• Una vez que el usuario entra en sesión y selecciona el servicio de Editar Documento, elige la plantilla o documento dentro de sus archivos anteriores.

• Hace la petición de borrar el documento cargado. Se hace la conexión con el sistema de directorios.

• Se realiza la búsqueda del documento a eliminar y se procede a borrarlo de la rama correspondiente.

• El usuario puede ver su lista de documentos anteriores actualizada. Se termina la conexión con el árbol.

Cargar documento o plantilla

• El usuario ha entrado en su sesión, ha elegido el servicio de Editar Documento y selecciona un documento o plantilla que haya guardado anteriormente.

• Se realiza una conexión con el árbol para saber la ruta del documento solicitado, así como el certificado del usuario.

• Se verifica la integridad del documento mediante el certificado del usuario.

• Si la verificación de la firma del documento es exitosa, éste se muestra en el editor.

• Se cierra la conexión con el sistema de directorios. El usuario puede seguir editándolo.

Cargar documento recibido

• El usuario entra en sesión y ve en su página personal los documentos que ha recibido por parte de otro usuario.

• Da clic en el que desea abrir y se establece la comunicación con el árbol.

• Se hace una búsqueda del certificado del emisor del documento seleccionado.

• Se hace una verificación de firma del documento con el certificado previamente solicitado.

• Si la verificación no se realiza satisfactoriamente, se vuelve a hacer con certificados anteriores del emisor (en caso de que los tenga).

• Si se comprueba la integridad con un certificado anterior, se notifica al usuario.

• Se muestra el documento no modificable y los datos pertinentes.

• Termina la comunicación con el sistema de directorios. Cargar documento recibido de la secretaria

• Una vez que el usuario entra en sesión y se muestran los documentos recibidos por parte de su secretaria (si es el caso), puede seleccionar el que desee para comenzar el proceso.

• Se hace la conexión con el sistema de directorios y se busca el certificado de la secretaria.

• Se verifica la firma con el certificado solicitado.

• Si el proceso no es exitoso, se buscan certificados anteriores de la secretaria y se vuelve a verificar.

• Si se puede verificar con un certificado revocado, se le notifica al usuario.

• Se muestra el documento en el editor de texto Kupu.

• Se termina la conexión con el sistema de directorios.

Establecer plantilla

• El usuario entra en sesión y elige el servicio d Editar Documento. Enseguida puede editar o abrir un documento anterior, haciendo una conexión al árbol.

• Se hace la petición de Establecer como Plantilla el documento actual del editor Kupu.

• Se pude un nombre de plantilla y se verifica que no exista en las plantillas anteriores del usuario.

• Si ya existe, se pedirá el consentimiento del usuario para poder sobrescribirlo.

• Si es afirmativo, se sobrescribe el nuevo contenido de la plantilla.

• De lo contrario se regresa al editor Kupu.

• Si la plantilla no existe, se agrega a la rama correspondiente.

• Se cierra la conexión con el sistema de directorios. Firmar un documento a enviar

• El usuario ya ha editado o abierto un documento que desea enviar. Hace la petición y se establece la conexión con el sistema de directorios.

• Se pide un nombre de documento y se comprueba que no exista. De lo contrario se preguntará al usuario si quiere sobrescribirlo. Se guarda el documento.

• Se busca la llave privada del usuario para realizar la firma.

• El documento se firma y se procede a mostrarlo finalmente (Documento, firma y emisor).

• Se buscan todos los contactos y los grupos que tenga el usuario, y se muestran.

• El usuario selecciona un destino, ya sea contacto, grupo o ambos. Se hace una comparación para obtener el identificador de los destinos sin que alguno se repita.

• Se hace la petición de enviar el documento.

• Se guarda el documento en la rama de documentos recibidos de cada usuario destino.

• Se termina la conexión con el árbol. Guardar un documento

• El usuario ha editado o abierto un documento. Se hace la petición de Solo guardar.

• Se realiza la conexión con el árbol y se busca la llave privada del usuario.

• Se pide un nombre de documento y se comprueba si ya existe tal nombre.

• Se firma el documento.

• Se muestra el documento de nuevo en el editor Kupu.

• Se termina la conexión. C. Caso de uso Gestión de Contactos. Se refiere al manejo de los contactos y grupos de contactos en la interfaz del usuario. Son utilizados para seleccionar los destinos de un documento. Los casos de uso relacionados con la gestión de contactos se muestran en la figura 15. Cualquier usuario tiene la posibilidad de añadir contactos en su lista. De otro modo no podrá enviar documentos. Los casos de uso se describen a continuación.

Crear Grupos.- Se refiere a la posibilidad de tener conjuntos de contactos para enviar documentos de modo masivo. Esta sección se solicitará un nombre de grupo. Modificar grupos.- Se refiere a modificar el nombre del grupo e inclusive hacer cambios con los contactos (agregar, borrar) y con sus nombres.

Borrar Grupos.- Es la eliminación del grupo seleccionado, así como su contenido. El grupo se borrará de la rama correspondiente, pero los contactos dentro de él seguirán en la lista de contactos.

Agregar Contactos.- Es la inserción de hojas en el sistema de directorios que corresponden a contactos. Se pedirá el identificador y el nickname deseado.

Eliminar contactos.- Se refiere a supresión de las hojas correspondientes a los contactos en el árbol de directorios.

Los cambios se reflejarán al momento de realizar cualquier acción, ya que se regresa a la interfaz correspondiente.

Los escenarios de la interfaz para la gestión de contactos y grupos se describen a continuación. Agregar contacto

• Se realiza la petición: Contactos. Se realiza una conexión con el sistema de directorios.

• Si la conexión es exitosa, se busca en la carpeta de Contactos del usuario, el contenido de la misma.

• En caso de no tener contactos, sólo habrá la opción de agregar. En caso contrario se mostrarán todos los contactos, ordenados por identificador – nickname.

• Se pide Agregar un Contacto. En ese momento se necesita el identificador BoletaCurp.

• Se verifica que exista un usuario con ese identificador y que no esté en la lista de contactos. Seguidamente se pide el nickname, en caso de obtener éxito en la búsqueda anterior.

• Se agrega el contacto en la rama correspondiente, y se muestra la lista de contactos actualizada.

• Finalmente se cierran todas las conexiones con el sistema de directorios.

Figura 15. Casos de uso correspondientes a la gestión de contactos

Crear grupos

• Se realiza la petición de Grupos de Contactos. A continuación se selecciona Crear Grupos.

• Enseguida se pedirá el nombre del grupo que se quiere crear.

• Se realiza una conexión con el sistema de directorios. Se busca que no exista un grupo con el nombre escrito anteriormente.

• Se crea la rama del grupo y se muestra la lista de contactos a agregar. Agregar miembro a grupo

• Se hace la petición de Agregar a Grupo. Se realiza una conexión con el árbol. Y se hace la consulta de contactos.

• Se muestran todos los contactos que se tienen, para poder agregarlos al grupo.

• Si se decide agregar un miembro de la lista de contactos, se selecciona de la lista mostrada.

• Se incluye el miembro dentro del grupo correspondiente.

• Si se decide incluir un miembro que no exista en la lista de contactos, se piden los datos de BoletaCurp y el Nickname para realizar la búsqueda y comprobar que por lo menos exista en el sistema de directorios.

• Si existe el usuario, se añade al grupo.

• Se terminan las conexiones con el sistema de directorios.

Modificar nickname del miembro de un grupo

• Una vez que muestra el contenido de un grupo, se hace la petición de cambio de nick simplemente dando clic sobre el mismo.

• Se pide el nuevo nickname por el que se reemplaza el anterior.

• Como un miembro puede pertenecer a varios grupos, se hace una búsqueda del miembro en todos los grupos.

• Se actualiza el nickname del miembro en todos los grupos al que pertenezca, inclusive en la rama de contactos.

• Se muestra el contenido del grupo con la modificación correspondiente.

• Se terminan todas las conexiones con el árbol de directorios. Borrar contacto

• Una vez que se muestran los contactos de un usuario, se pueden agregar o borrar. Para el caso de borrar, se selecciona el contacto a borrar.

• Debido a que el contacto puede pertenecer a algún grupo, se realiza una conexión al sistema de directorios, para buscar los grupos en donde se encuentre el contacto.

• Se elimina de los grupos donde exista y al final de la lista de contactos.

• Se muestra la lista de contactos actualizada. Se finalizan la conexión con el árbol. Borrar Grupo

• Cuando se muestren los grupos que tenga el usuario, se hace la petición de Borrar Grupos una vez seleccionando al grupo(s) que se quieren eliminar.

• Se realiza una conexión al sistema de directorios, y se eliminan los miembros de los grupos.

• Después se elimina la rama del grupo correspondiente.

• Se muestra la lista de grupos actualizada.

• Se cierra la conexión con el árbol.

Borrar miembro de grupo

• Una vez que se muestran los grupos del usuario, se puede ver quiénes lo integran dando clic sobre el nombre del mismo.

• Cuando se muestran los miembros del grupo, se selecciona el(los) que se desee eliminar y se hace la petición de Borrar Miembro.

• Se hace una conexión con el árbol de directorios y se elimina el miembro de la rama correspondiente.

• Se muestra el contenido del grupo. Se termina la conexión.

D. Caso de uso Auditoría. La auditoría es el proceso de registrar los eventos que el usuario esta realizando en el sistema para tener una bitácora de actividades y poder identificar anomalías. Las actividades que se registran son varias: autenticarse, guardar un documento, enviar un documento. En el caso del administrador también se registrarán las acciones que realiza, generar un certificado, revocar un certificado, borrar un usuario del reino de Kerberos correspondiente, dar de alta un usuario en Kerberos. El proceso de auditoría se base en 2 acciones:

• Recibir acción realizada por el usuario. El sistema recibe las acciones que ha

realizado en las diferentes páginas del sistema visitadas por el usuario, luego clasifica las acciones (administración de Kerberos, generación de documentos y escrituras/lecturas en el árbol de LDAP, administración de los certificados de los usuarios) y son enviadas al servidor central y éste las registra.

• Guardar en archivo log. El servidor central recibe las acciones de los servidores gateway y las guarda en las el archivo log correspondiente a la acción.

E. Caso de uso Archivo Muerto.

De acuerdo a la Ley de Conservación de la Información, la información en formato electrónico deberá ser guardar por un período de tiempo de acuerdo a su clasificación. Además cada institución que maneje documentos electrónicos deberá tener el software correspondiente para visualizar dichos documentos electrónicos generados.

Las acciones que realiza este caso de uso son:

Recibir documento electrónico.- Una vez que el usuario envía un documento, el módulo de archivo muerto recibe el nombre del documento enviado para posteriormente buscarlo en el árbol de directorios y buscar sus características.

Clasificar el documento.- El emisor deberá especificar el tipo de documentos que elabora, para que posteriormente éste módulo guarde el documento generado en el respectivo tipo de documento.

Guardar documento electrónico en el árbol de directorios.- Para guardar el documento, el sistema verifica que el emisor y el destinatario se encuentren registrados en el sistema. Posteriormente el módulo realiza una copia del documento en la carpeta correspondiente.

Existe un módulo dentro del archivo muerto llamado baja documental. Éste realiza el proceso de baja documental del archivo histórico (expurgo), esta tarea se realiza automáticamente cada día a una hora determinada.

• Elaborar listado de archivo que ya prescribieron. El módulo buscará los documentos que ya hayan prescrito, y elabora una lista de esos documentos de acuerdo al tiempo que deben durar como archivo histórico.

• Dar de baja archivo muerto. De acuerdo a la lista elaborada, los documentos son movidos en el árbol de directorios hacia el archivo histórico. Este archivo será el que se envié a área central del Instituto Politécnico Nacional.

3.2.2. Fase de Implementación. Para la implementación de este módulo se empleo el lenguaje de programación PERL, para aprovechar las ventajas que tiene en el manejo de script y así facilitar la configuración y gestión de información en Kerberos. Además permite implementar el MVC a través de Mypol, el cual esta orientado a aplicaciones WEB. Además está diseñado para minimizar la longitud de código y es capaz de crear una interfaz con medios de almacenamiento, como el árbol de directorios o una base de datos.

En cuestión a la parte de Vista, se utilizó Mason, que permite introducir código PERL en HTML. De esta manera se pueden generar páginas dinámicas, donde se visualice información diferente de acuerdo a una cierta condición. Utiliza una sintaxis de tags (marcas) donde se indica en qué partes se utiliza código PERL y en qué otras se usa código HTML.

Para la parte de Controlador, se usa el concepto de componente. Un componente es un elemento que permite realizar acciones, ya sea interactuando con el sistema de directorios o con la página HTML, pudiendo llamar a un componente dentro de otro. Mason también permite el uso de componentes dentro de páginas HTML. En el SSISA los componentes fueron páginas HTML con formato PERL.

Para almacenar la información y los documentos se emplea OPENLDAP. Debido a que este módulo implementa una interfaz WEB, es necesario hacer uso de un servidor WEB, en este caso Apache. Se eligió Apache por tener un módulo que interpreta código PERL, llamado mod_perl, que permite interpretar el código PERL de los componentes realizados con Mason.

Para garantizar el servicio de confidencialidad en el canal de comunicación, se configura la Capa de Sockets Seguros (SSL). Esto se realizó especificando un certificado y una llave

para el servidor. Además de especificar en el script de configuración de SSL y los mecanismos de cifrado. Para crear el certificado del servidor:

openssl req -x509 -newkey rsa:1024 -keyout key-server-<reino>.pem -out cert-server-<reino>.pem Después se copia a la carpeta correspondiente y se indica al Apache su ubicación:

SSLCertificateFile conf/ssl.crt/server.crt/serverf.pem SSLCertificateKeyFile conf/ssl.crt/server.key/key-server.pem

Además se tiene que generar un archivo/certificado para el paquete curl, que es el que realiza la verificación de los certificados del servidor. Para esto se forma un archivo con la huella del certificado, el certificado en base 64 y el certificado en texto claro:

MD5 Fingerprint=4E:45:0B:A0:7D:9A:8F:00:B6:BF:E5:1A:1D:BF:73:FE PEM Data: -----BEGIN CERTIFICATE----- MIID7DCCA1WgAwIBAgIJAP5K1K26ZhFOMA0GCSqGSIb3DQEBBAUAMIGrMQswCQYD VQQGEwJNWDEUMBIGA1UECBMLTWV4aWNvIEQuRi4xEjAQBgNVBAcTCVphY2F0ZW5j bzEaMBgGA1UEChMRVVBJSVRBLVBST0ZFU09SRVMxDjAMBgNVBAsTBVNTSVNBMRY FAYDVQQDEw0xOTIuMTY4LjIyNi42MS4wLAYJKoZIhvcNAQkBFh9zZXJ2ZXItcHJv ZmVzb3Jlc0B1cGlpdGEuaXBuLm14MB4XDTA1MDYwMzA4NDgzMFoXDTA1MDcwMzA4 NDgzMFowgasxCzAJBgNVBAYTAk1YMRQwEgYDVQQIEwtNZXhpY28gRC5GLjESMBAG A1UEBxMJWmFjYXRlbmNvMRowGAYDVQQKExFVUElJVEEtUFJPRkVTT1JFUzEOMAwG A1UECxMFU1NJU0ExFjAUBgNVBAMTDTE5Mi4xNjguMjI2LjYxLjAsBgkqhkiG9w0B CQEWH3NlcnZlci1wcm9mZXNvcmVzQHVwaWl0YS5pcG4ubXgwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMkHsejCIOp61yp1iYj9GF99UnkeRkdgLbdPG8LAnJ0p Ur3n9fCder1lTZ3a7bk92tnOxra0VSOXoAwFiZlkf+G51N4wHs9sqqTqjziLywAr 9w8fJVQnHVg2Lw8riPgb9KjwCzM0DhhYYhOnVqJyl7LZ6JRBWhu+V5Lr/rVS5QUf AgMBAAGjggEUMIIBEDAdBgNVHQ4EFgQU9VapamM0DTEqsSO7olBPyLyHU2IwgeAG A1UdIwSB2DCB1YAU9VapamM0DTEqsSO7olBPyLyHU2KhgbGkga4wgasxCzAJBgNV BAYTAk1YMRQwEgYDVQQIEwtNZXhpY28gRC5GLjESMBAGA1UEBxMJWmFjYXRlbmNv MRowGAYDVQQKExFVUElJVEEtUFJPRkVTT1JFUzEOMAwGA1UECxMFU1NJU0ExFjAU BgNVBAMTDTE5Mi4xNjguMjI2LjYxLjAsBgkqhkiG9w0BCQEWH3NlcnZlci1wcm9m ZXNvcmVzQHVwaWl0YS5pcG4ubXiCCQD+StStumYRTjAMBgNVHRMEBTADAQH/MA0G CSqGSIb3DQEBBAUAA4GBAEXB+DKjSlHaBQHePDlmzburFZcsr1KeYfZwc0kd/6n4 Xkdyd48hrcPN//YJH6XXxeB6uJRZM+A2sHmLzq6S3v7pODPT5E3+z/e99UPn36Ab ZGJ2uuIRJ2TjFzIPvQgBwShp3Ai0QWhq1i7UrKlAFo9Gh33WSXgNjihRELTMwKXJ -----END CERTIFICATE----- Certificate: Data:

Version: 3 (0x2) Serial Number: fe:4a:d4:ad:ba:66:11:4e Signature Algorithm: md5WithRSAEncryption Issuer: C=MX, ST=Mexico D.F., L=Zacatenco, O=UPIITA-PROFESORES, OU=SSISA, CN=192.168.226.6/emailAddress=server-profesores@upiita.ipn.mx

Validity Not Before: Jun 3 08:48:30 2005 GMT Not After : Jul 3 08:48:30 2005 GMT

Subject: C=MX, ST=Mexico D.F., L=Zacatenco, O=UPIITA-PROFESORES, OU=SSISA, CN=192.168.226.6/emailAddress=server-profesores@upiita.ipn.mx Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit):

00:c9:07:b1:e8:c2:20:ea:7a:d7:2a:75:89:88:fd: 18:5f:7d:52:79:1e:46:47:60:2d:b7:4f:1b:c2:c0: 9c:9d:29:52:bd:e7:f5:f0:9d:7a:bd:65:4d:9d:da: ed:b9:3d:da:d9:ce:c6:b6:b4:55:23:97:a0:0c:05: 89:99:64:7f:e1:b9:d4:de:30:1e:cf:6c:aa:a4:ea: 8f:38:8b:cb:00:2b:f7:0f:1f:25:54:27:1d:58:36: 2f:0f:2b:88:f8:1b:f4:a8:f0:0b:33:34:0e:18:58: 62:13:a7:56:a2:72:97:b2:d9:e8:94:41:5a:1b:be: 57:92:eb:fe:b5:52:e5:05:1f

Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: F5:56:A9:6A:63:34:0D:31:2A:B1:23:BB:A2:50:4F:C8:BC:87:53:62 X509v3 Authority Key Identifier: keyid:F5:56:A9:6A:63:34:0D:31:2A:B1:23:BB:A2:50:4F:C8:BC:87:53:62 DirName:/C=MX/ST=Mexico

D.F./L=Zacatenco/O=UPIITA-PROFESORES/OU=SSISA/CN=192.168.226.6/emailAddress=server-profesores@upiita.ipn.mx

serial:FE:4A:D4:AD:BA:66:11:4E X509v3 Basic Constraints: CA:TRUE Signature Algorithm: md5WithRSAEncryption 45:c1:f8:32:a3:4a:51:da:05:01:de:3c:39:66:cd:bb:ab:15: 97:2c:af:52:9e:61:f6:70:73:49:1d:ff:a9:f8:5e:47:72:77: 8f:21:ad:c3:cd:ff:f6:09:1f:a5:d7:c5:e0:7a:b8:94:59:33: e0:36:b0:79:8b:ce:ae:92:de:fe:e9:38:33:d3:e4:4d:fe:cf: f7:bd:f5:43:e7:df:a0:1b:64:62:76:ba:e2:11:27:64:e3:17: 32:0f:bd:08:01:c1:28:69:dc:08:b4:41:68:6a:d6:2e:d4:ac: a9:40:16:8f:46:87:7d:d6:49:78:0d:8e:28:51:10:b4:cc:c0:

a5:c9 También se tienen que configurar las carpetas que estarán protegidas, es decir, donde se utilizará un canal seguro. Así como la página de logeo por default una vez que se termine la sesión del usuario:

<Location /admin> WebAuthExtraRedirect on Require valid-user AuthType WebAuth WebAuthCred krb5 WebAuthUseCreds on WebAuthCred krb5 krbtgt/ALUMNOS.UPIITA.IPN.MX@ALUMNOS.UPIITA.IPN.MX

WebAuthFailureURL /index.html </Location>

4. Resultados Como resultado obtenido se obtuvo el portal WEB para los servicios del departamento de Control Escolar y el departamento de Biblioteca. Además se obtuvo una herramienta que permite la gestión segura de documentos entre miembros de la comunidad de la UPIITA, esta gestión se realiza aplicando firmas electrónicas, certificados, ley de transparencia de la información y la ley de conservación de la información. A continuación se muestran las pantallas principales del portal WEB.

Figura 15. Página Principal del Portal de servicios: Vista del Administrador

Figura 16. Página Principal del Portal de servicios: Vista del Alumno