Portafirmas V2. Manual de Instalación

Transcripción

1 Versión: INS009 Fecha: 22/11/2010

2 Versión 2.2.0

3 HOJA DE CONTROL Organismo Proyecto Entregable Autor Consejería de Economía, Innovación y Ciencia Portafirmas V2 GuadalTEL S.A. Versión/Edición INS009 Fecha Versión 22/11/2010 Nº Total de Páginas 69 REGISTRO DE CAMBIOS Versión Causa del Cambio Responsable del Cambio Fecha del Cambio INS001 Versión inicial FJCV 15/06/2009 INS002 Actualización FJCV 30/09/2009 INS003 Actualización FJCV 09/12/2009 INS004 Actualización FJCV 23/02/2010 INS005 Actualización FJCV 17/03/2010 INS006 Actualización FJCV 26/04/2010 INS007 Actualización FJCV 11/06/2010 INS008 Actualización FJCV/MJVR 20/09/2010 INS009 Cambio de Formato FJCV 24/09/2010 CONTROL DE DISTRIBUCIÓN Nombre y Apellidos Página 3 de 69

4 María Luisa de la Vega Royo Manuel Baena Fernández Fran Cantero Villar Miguel Jesús Vázquez Rebollo ÍNDICE 1 INTRODUCCIÓN Objeto Alcance DESCRIPCIÓN DEL SISTEMA Antecedentes Descripción funcional del sistema Nuevos procesos de firma Nuevas funcionalidades Evolución tecnológica Soluciones de movilidad Componentes Fundamentales RECURSOS HARDWARE Servidores Estaciones cliente Conectividad Restricciones RECURSOS SOFTWARE Restricciones técnicas del sistema Relación con otros sistemas Planificación de procesos Procesos planificados Página 4 de 69

5 5 INSTALACIÓN Y CONFIGURACIÓN DEL SOFTWARE BASE Instalación sobre Oracle Procedimiento primera instalación Tablespaces Usuario propietario Permisos Permisos interfaz PLSQL (opcional) Usuario de aplicación Creación del modelo de datos Carga inicial de datos Alta de usuario administrador Procedimiento de migración Consideraciones previas Descripción del proceso Recomendaciones Migración Eliminación de dependencias V1.X Revisión y adecuación de tablespaces Carga de procedimientos de migración Limpieza de datos Migración Actualización del modelo de datos Actualización de secuencias Carga de datos de configuración Actualización de estadísticas de índices Usuario administrador Interfaz PLSQL (Opcional) Instalación sobre PostgreSQL Procedimiento primera instalación Página 5 de 69

6 Creación del rol de conexión Tablespaces Creación del esquema Creación del modelo de datos Carga inicial de datos Alta de usuario administrador Configuración automatizada con Maven Perfiles de configuración Personalización del perfil configuración Ejemplo base de datos Oracle Ejemplo base de datos PostgreSQL Perfiles servidor aplicaciones Perfiles repositorios Compilación y empaquetado Configuración Manual Configuración de Hibernate Bases de datos Oracle PostgreSQL Usuario y clave Configuración Quartz Bases de datos Oracle PostgreSQL Usuario y clave Empaquetado INSTALACIÓN Y CONFIGURACIÓN DEL SISTEMA Procedimiento de instalación Tomcat 5.X Página 6 de 69

7 6.1.2 Tomcat 6.0 o JBoss GA JBoss GA Creación de pool de conexiones Librerías JDBC Librería de Quartz Despliegue Procedimiento de configuración General Parámetros Configuración de modos de acceso Configuración de avisos por correo Configuración de informes de firma Configuración proxy Configuración de Custodia Tipos de documentos Aplicaciones Servidores Parámetros MARCHA ATRÁS DE LA INSTALACIÓN Y CONFIGURACIÓN Preparación de marcha atrás Marcha atrás del sistema Marcha atrás del software base ANEXOS GLOSARIO BIBLIOGRAFÍA Y REFERENCIAS Página 7 de 69

8 1 INTRODUCCIÓN 1.1 Objeto El objetivo del presente documento es servir de guía en la instalación o migración de Portafirmas v2. Bien sea una instalación desde cero o proceda de una versión anterior v1.x. En éste último caso será necesario proceder a la traducción de las informaciones ya existentes al nuevo modelo, proceso que se describe en este mismo documento. Toda la instalación esta basada en scripts de base de datos que pueden ser ajustados por los Administradores de Base de Datos para revisar los parámetros de configuración a normas internas de implantación de aplicaciones en producción, o bien, a valores más reales a sus entornos de funcionamiento. El documento tiene dos grandes bloques diferenciados. Instalación desde cero en un esquema en limpio, o bien el proceso de migración de un esquema de Portafirmas v1.x a Portafirmas v2. Este segundo proceso será más ampliamente descrito para que quede claro las implicaciones del mismo, valoración aproximada del tiempo medio de duración del proceso así como el resultado final obtenido. 1.2 Alcance El presente documento esta dirigido a los siguientes perfiles de usuario: Responsables del comité de dirección del proyecto para la validación y adecuación del mismo a las normas definidas en MADEJA. Responsables de una administración que estudien la viabilidad de instalación del producto así como compilen y empaqueten el proyecto en función al entorno local de ejecución. Administradores de Base de datos, para analizar requisitos de instalación y realizar los procesos necesarios a nivel de instalación/migración de base de datos. Administradores de Sistema para analizar requisitos de instalación, intercomunicación con otros sistemas y que desplieguen la aplicación previamente paquetizada para el entorno local escogido. Página 8 de 69

9 2 DESCRIPCIÓN DEL SISTEMA 2.1 Antecedentes La versión 1 de Portafirmas nació como un gestor de documentos para la firma digital de los mismos de forma sencilla por parte de los usuarios así como para facilitar la integración de la firma en terceras aplicaciones. Dirigido inicialmente para altos cargos, la práctica ha llevado a que se use a todos los niveles de la administración, desde la firma de resoluciones a tiquets de taxi. Su filosofía de ofrecer un interfaz común a los procesos de firma indistintamente del procedimiento ha llevado a una prolífera integración en multitud de aplicaciones existentes o de nuevo desarrollo. Ha ayudado a superar la brecha que supone abandonar el papel y pasar a formatos electrónicos, acercando la firma digital a todos los usuarios. 2.2 Descripción funcional del sistema Fruto del uso diario de Portafirmas en distintos procedimientos administrativos y entornos, surgen a lo largo de los años nuevos requisitos, ya no solo como evolutivo a los tecnologías más actuales, sino tratar de cubrir un mayor número de casos dentro de la administración. Nace así Portafirmas V2 con los siguientes nuevos objetivos Nuevos procesos de firma Petición de firma a un cargo o puesto de trabajo, el cual puede estar ostentado por una o varias personas. Firma de primer firmante, cuando necesitamos una firma y se remite a varios posibles firmantes, siendo válido el proceso con que uno solo de ellos lo firme. Intercalar VºBº en un proceso de firma, requerir que una determinada persona o cargo de un visto bueno antes de pasar la firma a un alto cargo. Delegación de firma, recogiendo los tres casos existentes: Delegación Sustitución Avocación Página 9 de 69

10 2.2.2 Nuevas funcionalidades Aplicación configurable por perfil, cada usuario solo podrá hacer lo que tenga autorizado. Filtros, etiquetas, archivado de peticiones y distintas herramientas orientadas todas ellas a mejorar la gestión. Posibilidad de incluir los anexos que no se firman directamente en la petición sin necesidad de incluir la información en texto de explicación. Metadatos asociado a una petición, cada aplicación puede definir cuales son las informaciones quieren que se muestren en su bandeja y petición. Posibilidad de incluir comentarios entre usuarios dentro de una petición, para reducir así los rechazos cuando se presenta por el firmante alguna duda. Gestión de autorizaciones entre usuarios para reglas de delegación, acceso por terceros en modo consulta al Portafirmas, remisión entre usuarios, etc. Nuevo interfaz más sencillo y simple. Se reducen al mínimo el número de pasos para cada proceso (firma, rechazo, etc). Internacionalización y distintos temas visuales, cada usuario define el idioma, la distribución de elementos y el tema más acorde a su gusto. Integración con gestor documental, la información binaria se puede recoger entre distintas fuentes de datos. Unicidad de documentos, el mismo binario se guarda una sola vez, pero se puede vincular a múltiples peticiones. Firma PDF de los informes de firma. Nueva versión de Verifirma v2 que requiere autenticación de usuario mediante certificado. Nuevo código de verificación segura. Monitorización mediante NAGIOS y trazas mediante la evolución de Log4j, Logback Evolución tecnológica Reescritura completa del núcleo de PLSQL a Java, nuevo modelo de datos acorde a todas las nuevos requisitos y proceso de migración paso a paso del antiguo al nuevo incluido en el kit. Página 10 de 69

11 Adopción de MADEJA, fuentes en Maven, validación de calidad de código por Sonar y licencia EUPL. MVC JSF Richfaces con núcleo transaccional JBoss Seam e Hibernate JPA. Arquitectura SOA. Integración inicial usando los servicios nativos (eliminación de extensión). Compatibilidad hacia atrás con aplicaciones que integrasen con Portafirmas v1.x, tanto por servicios web como por API PLSQL Soluciones de movilidad Acceso desde dispositivos móviles y tablet pc's., interfaz mejorada y adaptada para tales dispositivos. Firma móvil, ya sea mediante un cliente ligero o bien mediante otros mecanismos de firma recogidos en el Art.16 de la Ley 11/2007. Interconexión entre distintos Portafirmas, posibilidad de ver peticiones pendientes entre distintas instancias de Portafirmas y firma remota de los mismos. Avisos vía SMS a los destinatarios o remitentes de las peticiones de distintos eventos o notificaciones que ya reciben por correo. Acceso a las bandejas de peticiones a determinados usuarios autorizados por protocolo IMAP como si fuera una cuenta de correo normal. 2.3 Componentes Fundamentales Módulo Web Portafirmas Servicios Web V1 Servicios Web V2 Descripción Portal Web de Portafirmas electrónico Antiguos servicios web rpc/literal Nuevos servicios web document/literal Página 11 de 69

12 3 RECURSOS HARDWARE 3.1 Servidores Dato Sistema Operativo Memoria RAM Tamaño Almacenamiento Valor Linux o Windows. 1GB mínimo para poder dedicar un 60 70% al servidor de aplicaciones. 2 5GB libre en disco, para despliegue de la aplicación, temporales y archivos de log o traza. 3.2 Estaciones cliente Disponer de un runtime Java compatible con el Un navegador que cumpla los requisitos definidos por la propia en su versión v5. Certificado personal de usuario admitido por la en su versión v5. Para acceder a la información relacionada acceder a Plutón, Área Técnica Conectividad Conectividad con los servicios web de firma: Una instancia local a la instalación. de Administración Pública accesible desde RCJA. publicada vía red S.A.R.A para las administraciones públicas. 3.4 Restricciones Página 12 de 69

13 Elemento Detalles de la Restricción Página 13 de 69

14 4 RECURSOS SOFTWARE 4.1 Restricciones técnicas del sistema Dato Sistema Operativos JVM Valor Linux o Windows JDK 1.5.0_X ó 1.6.0_X Compilado Maven 2.0 JDK 1.5 Servidor Aplicaciones Apache Tomcat 5.5 ó 6.0 JBoss GA ó GA Base de Datos Oracle 10G o superior (versión recomendada ). PostgreSQL 8.1 o superior. (No testada aún en 9) Servidor de 5.2.X o 5.3.X. No funciona correctamente en versiones 5.0 por diferencias entre versiones. No es necesaria la custodia. El sellado de tiempo es opcional a decisión de cada instalación si bien recomendable para no repudio. Existe una versión de JBoss 4.2.3GA para JDK 1.6, pero en entornos de alta concurrencia de usuarios puede dar problemas de conexiones abiertas No se recomienda por tanto esta configuración. 4.2 Relación con otros sistemas Sistema 5.2.X ó 5.3.X, uso de servicios nativos de autenticación, firma en bloque, firma en dos fases Obligatorio Página 14 de 69

15 SMTP y verificación. Servidor de correo SMTP para el envío de avisos por correo electrónico. Recomendado LDAP Autenticación de usuarios mediante LDAP. Opcional Alfresco Custodia sobre Gestor Documental Alfresco. Opcional 4.3 Planificación de procesos Procesos planificados Proceso Fechas de Ejecución Estimada Inicio Fin Dependencias Demonio de pre firma 00:00 Conexión con los servicios de firma. El Demonio de pre firma se configura desde la administración, donde se define que días se ejecuta y la hora de inicio del mismo. El tiempo de ejecución depende del número de peticiones pendientes existentes. El demonio de pre firma sirve SOLO para configuraciones de firma en bloque. Página 15 de 69

16 5 INSTALACIÓN Y CONFIGURACIÓN DEL SOFTWARE BASE 5.1 Instalación sobre Oracle Distinguimos dos casos, instalación desde cero o migración desde una v1.x Procedimiento primera instalación En este apartado del documento se describe el proceso de instalación desde cero así como la carga inicial de parámetros de configuración Tablespaces En nuestra instancia de base de datos tenemos que tener definidos los siguientes tablespaces: TS_PFIRMA_INDICES: El tamaño inicial 16MB. TS_PFIRMA_DATOS: El tamaño inicial 64MB. TS_PFIRMA_BLOB: El tamaño inicial 128MB. Se recomienda activar la opción de crecimiento automático. El tamaño de chunk es algo complejo de definir a priori. Un tamaño pequeño repercute en un mejor aprovechamiento del espacio pero un mayor número de llamadas a disco, acceso por tanto más lento. Un tamaño mayor implica un mayor desaprovechamiento del espacio pero un acceso más rápido, al ser menor en numero de accesos al disco. Es por ello recomendable estudiar los valores obtenidos en el entorno de pruebas para poder extrapolar una configuración ajustada y equilibrada en producción. Los valores iniciales indicados inicialmente son un buen punto de partida, pero cada DBA puede ajustar los mismos a los valores que estime oportuno Usuario propietario Es necesario un usuario de base de datos para que sea el propietario de los objetos. Recomendamos que este sea el usuario PFIRMAMG, pues será el que empleemos como referencia en el resto del documento. El tablespace por defecto de este usuario sera TS_PFIRMA_DATOS y el temporal, TEMP o el definido en la instancia de base de datos como temporal. create user PFIRMAMG identified by <clave> Página 16 de 69

17 default tablespace TS_PFIRMA_DATOS temporary tablespace TEMP quota unlimited on TS_PFIRMA_INDICES quota unlimited on TS_PFIRMA_DATOS quota unlimited on TS_PFIRMA_BLOB; Permisos Los permisos que necesita el usuario propietario del esquema son: grant create session, alter session, alter user to PFIRMAMG; grant create table, create sequence, create procedure to PFIRMAMG; Permisos interfaz PLSQL (opcional) Si se va instalar la interfaz de aplicaciones PLSQL es necesario que el usuario propietario le sea concedido un permiso adicional: grant create type to PFIRMAMG; Usuario de aplicación Será el que se configure a nivel de la aplicación y solo tendrá acceso a los objetos de base de datos, pero no será propietario de los mismos. Para crearlo: create user PFIRMAWEB identified by <clave> default tablespace TS_PFIRMA_DATOS temporary tablespace temp; Los permisos iniciales para este usuario serán: grant create session, alter session, alter user to PFIRMAWEB; grant create synonym to PFIRMAWEB; El usuario propietario debe concederle permisos de SELECT, INSERT, DELETE, UPDATE sobre todos los objetos tabla, así como SELECT sobre todos los objetos secuencia. Deberá de crear además un sinónimo privado por cada objeto del esquema del propietario. En principio no deben hacerse sinónimos públicos sobre los objetos de Portafirmas dado Página 17 de 69

18 que esto puede dar la sensación de que se pueda acceder a los mismos, es mejor por motivos de seguridad solo hacer sinónimos privados a nivel de usuario web. Las terceras aplicaciones interactuarán con Portafirmas SIEMPRE por la API PLSQL o bien por la interfaz de servicios web publicada Creación del modelo de datos Una vez creado el usuario propietario probaremos a conectarnos con el mediante un cliente SQL, como el SQLPLUS, SQLDeveloper, TOAD o Tora. Tomemos el ejemplo de usar el SQLDeveloper, programa que se puede descargar de la página de Oracle. Introduciremos los datos de conexión a la base de datos y probaremos dicha conexión: Si la conexión es correcta podemos continuar a crear todas las entidades necesarias para Portafirmas, osease tablas, índices, restricciones y secuencias. Para ello hay que lanzar el siguiente script de base de datos: /pfirmav2/src/main/database/oracle/creacion/script_creacion.sql Lo cargamos en el SQLDeveloper y la damos a ejecutar: Página 18 de 69

19 Tras la ejecución se habrá creado el modelo de datos, podemos revisarlo rápidamente mirando los objetos básicos del usuario, tablas, secuencias, restricciones e índices Carga inicial de datos Para que la aplicación pueda funcionar es necesario una carga inicial de parámetros. Para ello hay que lanzar el siguiente script: /pfirmav2/src/main/database/oracle/creacion/script_datos.sql Al final del mismo se realiza el commit Alta de usuario administrador Para seguir con la configuración de la aplicación desde el interfaz de Portafirmas es necesario crear un primer usuario que será el que acceda mediante usuario/clave con la aplicación en modo DEBUG para terminar de configurar el resto de elementos. Primero crearemos el usuario: Insert into PF_USUARIOS (X_USUARIO, C_IDENTIFICADOR, D_NOMBRE, D_APELL1, D_APELL2, C_TIPO, L_VIGENTE) Página 19 de 69

20 Values (PF_S_USU.NEXTVAL, :DNI, :NOMBRE, :APELL_1, :APELL_2, 'USUARIO', 'S'); Luego le asignaremos una clave: Insert into PF_USUARIOS_PARAMETRO (X_USUARIO_PARAMETRO, T_VALOR, PAR_X_PARAMETRO, USU_X_USUARIO) Values (PF_S_UPAR.NEXTVAL, :CLAVE, (select X_PARAMETRO from pf_parametros where C_PARAMETRO='USUARIO.PASSWORD'), (select X_USUARIO from pf_usuarios where c_identificador=:dni)); Página 20 de 69

21 Le damos el perfil de acceso: Insert into PF_USUARIOS_PERFIL (X_USUARIO_PERFIL, F_INICIO, USU_X_USUARIO, PER_X_PERFIL) Values (PF_S_UPER.NEXTVAL, SYSDATE, (select X_USUARIO from pf_usuarios where c_identificador=:dni), (select X_PERFIL from pf_perfiles where c_perfil='acceso')); Y le asignamos el perfil de Administrador: Insert into PF_USUARIOS_PERFIL (X_USUARIO_PERFIL, F_INICIO, USU_X_USUARIO, PER_X_PERFIL) Values (PF_S_UPER.NEXTVAL, SYSDATE, (select X_USUARIO from pf_usuarios where c_identificador=:dni), (select X_PERFIL from pf_perfiles where c_perfil='admin')); Si todo es correcto, guardamos los cambios: commit; Página 21 de 69

22 5.1.2 Procedimiento de migración En este caso partimos desde una instalación de Portafirmas 1.X que ya contiene una serie de informaciones (configuraciones, usuarios, peticiones, documentos, firmas, etc), y queremos trasladar las mismas al nuevo modelo de datos. A continuación vamos a ver una descripción del proceso así como una serie de consejos previos antes de iniciar la migración Consideraciones previas Descripción del proceso Para reducir el volumen de información a migrar y que el proceso sea lo más rápido posible, en vez de hacer un proceso de volcado tradicional donde la información de un esquema origen se vuelca sobre un nuevo esquema destino, el proceso de migración de Portafirmas v2 lo que hace es traducir el modelo de datos actual al nuevo sin mover las informaciones. De esta forma, las tablas y los tablespaces que contienen un gran volumen de información no se mueven, sino lo que se hace es modificar el diccionario de tablas mediante operaciones de renombrado de columnas y tablas para adecuarlo al nuevo modelo. El proceso se describe en los siguientes pasos resumidos: Limpieza del esquema: Se elimina toda la información inservible y residual existente en Portafirmas V1, como registro de eventos o peticiones no entregadas a fecha del proceso de migración. Se eliminan las restricciones e índices sobre las tablas para poder hacer el renombrado de tablas y columnas. Se migra el modelo de datos. Se eliminan las tablas antiguas. Tras esto hay que lanzar un script que termina de complementar el modelo de datos con el resto de tablas necesarias, así como crea de nuevos las restricciones, índices y secuencias para las mismas. Por último para dejar el modelo de datos en óptimo funcionamiento se lanza un par de procedimientos que recalculan índices y inicializa correctamente las secuencias a los valores máximos de sus respectivas claves primarias. Página 22 de 69

23 Recomendaciones El proceso de migración no es reversible, es decir, una vez migrado el modelo de datos no se puede volver atrás sin tener que restaurar una copia de seguridad, por ello es MUY IMPORTANTE tener en cuenta las siguientes recomendaciones: Antes de iniciar el proceso de migración, revisar las informaciones de configuración y de servidores para que no haya informaciones no útiles, es decir, servidores dados de alta como prueba y cuyos datos sean incorrectos o bien aplicaciones o tipos de documentos dados de alta como pruebas y que no se estén usando realmente. Cuanto más limpia y útil sea la información a migrar mejor será el resultado final. Hacer copia de seguridad del esquema completo a migrar, por si hubiera algún problema, poder restablecer la situación inicial anterior al proceso. Una vez migrado un esquema, pedir a usuarios expertos que revisen y detecten posibles carencias en las informaciones que previamente tenían antes de iniciar el proceso de migración. Aunque el proceso de migración haya sido correcto en pruebas, es muy recomendable probar en dicho entorno un volcado de los datos de producción. El volumen de datos es exponencialmente superior y al reproducir el proceso de migración con tal volumen de datos puede protegernos de problemas en cuanto a dimensionamiento de tablespaces así como hacer una aproximación al tiempo de duración del proceso para los datos de producción. Esto nos dará una buena referencia para planificar el proceso de migración y mecanismos de vuelta atrás en caso de error. Sin más, pasamos a indicar proceso Migración Eliminación de dependencias V1.X Lo primero que haremos es eliminar el antiguo núcleo PLSQL de la v1.x así como dependencias que ya no son necesarias. Primero todos los paquetes de PLSQL, una forma sencilla es desde el navegador de objetos, pulsando sobre el botón derecho sobre el elemento, pulsamos sobre Drop Package. Página 23 de 69

24 Una vez eliminados todos los paquetes, eliminamos la clase auxiliar java de Base64, igual que antes, pero pulsando sobre Drop Class. También eliminaremos todas los jobs o tareas programadas existentes de portafirmas. Una vez eliminado estos elementos se puede pasar al siguiente paso Revisión y adecuación de tablespaces Durante el proceso de instalación de Port@firmas V1.X se recomendaba a usar los siguientes tablespaces: TS_PFIRMA_INDICES. TS_PFIRMA_DATOS. TS_PFIRMA_BLOB. El procedimiento de migración espera estos tres tablespaces inicialmente, en caso de existir y ser los usados dentro de mi sistema, continuar con el siguiente punto. En el caso de ser distintos por cumplir normas internas de gestión de base de datos, hay que actualizar las siguientes tres constantes existentes en la especificación del paquete PF_PQ_SYS.pks descrito en el siguiente punto: TABLESPACES Página 24 de 69

25 TS_DATOS CONSTANT VARCHAR2(30):='<TABLESPACE_DATOS>'; TS_INDICES CONSTANT VARCHAR2(30):='<TABLESPACE_INDICES>'; TS_BLOB CONSTANT VARCHAR2(30):='<TABLESPACE_BLOBS>'; Si al hacer el cambio da errores de truncamiento en ejecución revisar que el nuevo nombre no excede de tamaño treinta, y en ese caso, aumentar el tamaño de la constante al valor adecuado Carga de procedimientos de migración Ahora pasamos a cargar los procedimientos PLSQL encargados de limpiar y migrar el modelo de datos. Los scripts de estos paquetes se encuentran en: /pfirmav2/src/main/database/oracle/migracion/plsql/ Para ello cargaremos primero las especificaciones, y luego los cuerpos de los mismos en el siguiente orden. PF_PQ_SYS.pks PF_PQ_LOG.pks PF_PQ_MIGRACION.pks PF_PQ_SYS.pkb PF_PQ_LOG.pkb PF_PQ_MIGRACION.pkb Tras cargarlos comprobaremos que están todos y su estado es válido para poder pasar al siguiente punto Limpieza de datos Este proceso lo que hace es eliminar toda la información no necesaria en el esquema, principalmente trazas y peticiones no cerradas (que se iniciaron a dar de alta, pero nunca se llegaron a enviar. Para ello ejecutaremos lo siguiente: Begin pf_pq_migracion.clean_eventos(sysdate); Página 25 de 69

26 end; pf_pq_migracion.clean_cache(sysdate); pf_pq_migracion.clean_peticiones(sysdate); Este mismo proceso se lanza justo antes de migrar también, pero si lo adelantamos nos ahorramos este tiempo en el proceso de migración puramente. Además lo podemos ejecutar tantas veces como queramos antes de migrar Migración Es el proceso en sí de traducción del modelo de datos. Se limita a lanzar la siguiente linea de ejecución: Begin pf_pq_migracion.migration; end; Esto migrará completamente el modelo de datos a v1.x a v2, guardando los posibles errores en una tabla auxiliar PF_LOG. En nivel de traza se puede personalizar si queremos tener un mayor o menor detalle de la misma, siendo los posibles valores DEBUG, INFO o ERROR. Su funcionamiento es similar a Logback o Log4j. Por ejemplo, si queremos lanzar el proceso de migración a nivel DEBUG: Begin pf_pq_migracion.migration(pf_pq_log.log_debug); end; El resultado es que cada operación que se haga quedará registrada en la tabla anterior de trazas Actualización del modelo de datos Tras el proceso de migración habremos actualizados las tablas de V1.X a V2, pero falta una serie de nuevas entidades que no estaban anteriormente recogidas. Es por ello necesario lanzar el script de modificación que se encarga de crear el resto de tablas, establecer valores por defecto, restricciones, claves primarias, claves ajenas, secuencias e índices. Página 26 de 69

27 Para ello debemos lanzar el siguiente script: /pfirmav2/src/main/database/oracle/migracion/script_migracion.sql Tras lanzarlo ya tendremos el modelo de datos V2 completamente definido Actualización de secuencias Este paso se encarga de poner los valores iniciales a cada una de las secuencias existentes a los valores máximos de cada una de claves primarias de cada tabla. Para ello ejecutaremos lo siguiente: begin end; pf_pq_migracion.resequence; Carga de datos de configuración Una vez definido el modelo y actualizadas las secuencias, hay que cargarlo con el resto de informaciones de configuración complementarias a las importadas del esquema original. Para ello hay que lanzar el siguiente script: /pfirmav2/src/main/database/oracle/migracion/script_datos_migracion.sql Tras esto ya tendremos el modelo de actualizado y preconfigurado inicialmente Actualización de estadísticas de índices Ya tenemos el modelo de datos actualizado, si bien es importante dejar los índices de las tablas en su estado óptimo tras todo el proceso de migración. begin pf_pq_sys.compute_statistics; end; Una vez recalculados los índices podemos pasar a definir un usuario administrador que pueda terminar de configurar la aplicación desde el propio interfaz de Portafirmas. Página 27 de 69

28 Usuario administrador Si el usuario inicial de administración ya había entrado en Portafirmas, seguiremos este punto hacia adelante, si es nuevo, seguiremos los pasos indicados para el alta de un nuevo usuario administrador explicado en este mismo documento en la instalación desde cero. Para asociarle el perfil de administración a usuario existente lanzaremos los siguientes pasos, primero crearle una clave para que pueda entrar en modo DEBUG: Insert into PF_USUARIOS_PARAMETRO (X_USUARIO_PARAMETRO, T_VALOR, PAR_X_PARAMETRO, USU_X_USUARIO) Values (PF_S_UPAR.NEXTVAL, :CLAVE, (select X_PARAMETRO from pf_parametros where C_PARAMETRO='USUARIO.PASSWORD'), (select X_USUARIO from pf_usuarios where c_identificador=:dni)); Una vez creada la clave, le asociamos el perfil de administración: Insert into PF_USUARIOS_PERFIL (X_USUARIO_PERFIL, F_INICIO, USU_X_USUARIO, PER_X_PERFIL) Values (PF_S_UPER.NEXTVAL, SYSDATE, (select X_USUARIO from pf_usuarios where c_identificador=:dni), (select X_PERFIL from pf_perfiles where c_perfil='admin')); Si todo es correcto, guardamos los cambios: commit; Si necesitamos más usuarios administradores, ya desde el interfaz de administración puede crear nuevos usuarios, inicializar la clave, modificar perfiles, etc. Si por error se eliminan todos los usuarios administradores, se pueden repetir estos pasos pasos para volver a crear uno nuevo. Página 28 de 69

29 5.1.3 Interfaz PLSQL (Opcional) El núcleo de Portafirmas es ahora ya Java 100% en v2. Es por tanto que no es necesario ningún paquete de base de datos ni nada similar en base de datos. Pero si tenemos una instalación Oracle y nos interesa mantener la interfaz que se ofrecía vía PLSQL a terceras aplicaciones, principalmente aquellas desarrolladas sobre Oracle Forms, podemos habilitar los siguientes paquetes de PLSQL. Estos paquetes respetan completamente el API anteriormente publicada, si bien, no aportan nada nuevo funcionalmente, por lo que estas aplicaciones no podrán aprovecharse de los nuevas funcionalidades que se han incluido en v2. Si venimos desde una instalación desde cero, deberemos primero crear los tipos necesarios. Es importante haber tenido en cuenta que queremos hacer uso de la API PLSQL en el punto anterior en este manual referente a permisos, dado que sin estos permiso no podemos lanzar el siguiente script: /pfirmav2/src/main/database/oracle/migracion/script_tipos.sql El proceso de instalación se basa en cargar inicialmente las especificaciones y luego los cuerpos de los paquetes, es por ello que hay que seguir el siguiente orden al cargar los paquetes de base de datos. Estos se encuentran en la siguiente ruta: /pfirmav2/src/main/database/oracle/migracion/ El orden de las especificaciones sería: PF_PQ_SYS.pks PF_PQ_LOG.pks PF_PQ_TYPE.pks PF_PQ_API.pks PF_PQ_TOOL.pks PF_PQ_WEB.pks PF_PQ_LOOKUP.pks PF_PQ_PETICION.pks Página 29 de 69

30 El orden luego de los cuerpos sería: PF_PQ_SYS.pkb PF_PQ_LOG.pkb PF_PQ_TYPE.pkb PF_PQ_API.pkb PF_PQ_TOOL.pkb PF_PQ_WEB.pkb PF_PQ_LOOKUP.pkb PF_PQ_PETICION.pkb Una vez compilados, comprobaremos que son correctos. Los usuarios de base de datos que tenían acceso a la antigua API PLSQL deberán revisar los permisos sobre los objetos de Portafirmas, dado que habrán sido eliminados dichos permisos al borrar los objetos. En el documento Impacto de Portafirmas v2.0 se detallan los cambios a los que se puede ver afectada una aplicación que integrase anteriormente contra Portafirmas v1.x. Página 30 de 69

31 5.2 Instalación sobre PostgreSQL A continuación vamos a ver el proceso de instalación desde cero en una base de datos PostgreSQL. En este caso no hay migración, dado que no había V1.X sobre este tipo de base de datos Procedimiento primera instalación Partimos desde una instalación de PostgreSQL en la cual vamos crear una serie de nuevos objetos. Se recomienda usar el cliente pgadmin3 durante el proceso, a continuación se muestra capturas del proceso, si bien cada DBA puede personalizar el proceso de instalación a los requisitos internos de instalación. Página 31 de 69

32 Creación del rol de conexión Nos vamos al árbol de servidores, y el la rama de roles de login, le damos a la opción Nuevo rol de login.... Damos de alta el rol pfirmav2, con la clave que definamos. Es importante anotarla dado que nos será necesaria más adelante en el proceso: Le damos a aceptar y esto nos creará el nuevo rol de conexión, equivale al siguiente instrucción SQL: CREATE ROLE pfirmav2 LOGIN ENCRYPTED PASSWORD '****************************************' NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE; Es recomendable probar el usuario recién creado antes de continuar Tablespaces Para nuestra instancia de base de datos tenemos que crear los siguientes tablespaces: Página 32 de 69

33 TS_PFIRMA_INDICES. TS_PFIRMA_DATOS. Para ello creamos dos directorios donde prefiramos, para el caso de ejemplo: mkdir $HOME/Trabajo/BD/TS_PFIRMA_DATOS mkdir $HOME/Trabajo/BD/TS_PFIRMA_INDICES sudo chown postgres:postgres $HOME/Trabajo/BD/TS_PFIRMA_* Tras esto, creamos los dos tablespaces: Página 33 de 69

34 Las instrucciones SQL equivalentes serían: CREATE TABLESPACE "TS_PFIRMA_DATOS" OWNER pfirmav2 LOCATION '/home/xxx/trabajo/bd/ts_pfirma_datos'; CREATE TABLESPACE "TS_PFIRMA_INDICES" OWNER pfirmav2 LOCATION '/home/xxx/trabajo/bd/ts_pfirma_indices'; Creación del esquema Una vez creado el rol de conexión y tablespaces, queda crear el esquema. Para ello nos vamos dentro del árbol de Bases de Datos, sobre la base de datos en cuestión, esquemas, Nuevo esquema... Página 34 de 69

35 La sentencia SQL equivalente: CREATE SCHEMA pfirmav2 AUTHORIZATION pfirmav2; Página 35 de 69

36 Creación del modelo de datos Lo siguiente que nos queda ya entonces es conectarnos con el rol de conexión creado y crear las tablas necesarias para el sistema. Para ello hacemos una nueva conexión: Si la conexión es correcta, podremos acceder a la pantalla SQL sobre el esquema que hemos creado, en la cual podemos cargar el script existente en la siguiente ruta: /pfirmav2/src/main/database/postgresql/creacion/script_creacion_pg.sql Lo cargamos y le damos a ejecutar: Página 36 de 69

37 Tras la ejecución el modelo de datos estará creado, podemos revisarlo rápidamente comprobando que existe los objetos básicos de usuario, tablas, secuencias, restricciones e índices Carga inicial de datos Para que la aplicación pueda funcionar es necesario una carga inicial de parámetros, para ello hay que lanzar el siguiente script que se puede encontrar en: /pfirmav2/src/main/database/postgresql/creacion/script_datos_pg.sql Una vez cargado, le damos a ejecutar: Revisar luego mirando el contenido de las tablas que se han cargado los datos. Página 37 de 69

38 Alta de usuario administrador Para seguir con la configuración de la aplicación desde el interfaz de Portafirmas es necesario crear un primer usuario administrador que será el que acceda mediante usuario/clave con la aplicación en modo DEBUG para terminar de configurar el resto de elementos. Una vez creado este usuario, se puede asignar a más usuario el perfil de administrador si así fuese necesario. Se recomienda personalizar los valores que a continuación vienen marcados en rojo a modo de ejemplo, y en ningún caso dejar estos valores para entornos de producción. Para empezar crearemos el usuario administrador, para el caso de ejemplo, identificado mediante 'ADMIN', si bien puede ser el DNI de la persona que vaya a ser administrador del sistema, junto al resto de sus datos personales, nombre y apellidos: Insert into PF_USUARIOS (X_USUARIO, C_IDENTIFICADOR, D_NOMBRE, D_APELL1, D_APELL2, C_TIPO, L_VIGENTE) Values (nextval('pf_s_usu'), 'ADMIN', 'Administrador', 'Administrador', 'Administrador', 'USUARIO', 'S'); Luego le asignaremos una clave sencilla de recordar, si bien podemos poner otra de mayor complejidad a gusto del usuario en cuestión: Insert into PF_USUARIOS_PARAMETRO (X_USUARIO_PARAMETRO, T_VALOR, PAR_X_PARAMETRO, USU_X_USUARIO) Values (nextval('pf_s_upar'), '12345', (select X_PARAMETRO from pf_parametros where C_PARAMETRO='USUARIO.PASSWORD'), (select X_USUARIO from pf_usuarios where c_identificador='admin')); Le damos el perfil de acceso: Insert into PF_USUARIOS_PERFIL (X_USUARIO_PERFIL, F_INICIO, USU_X_USUARIO, PER_X_PERFIL) Values Página 38 de 69

39 (nextval('pf_s_uper'), now(), (select X_USUARIO from pf_usuarios where c_identificador='admin'), (select X_PERFIL from pf_perfiles where c_perfil='acceso')); Y le asignamos el perfil de Administrador: Insert into PF_USUARIOS_PERFIL (X_USUARIO_PERFIL, F_INICIO, USU_X_USUARIO, PER_X_PERFIL) Values (nextval('pf_s_uper'), now(), (select X_USUARIO from pf_usuarios where c_identificador='admin'), (select X_PERFIL from pf_perfiles where c_perfil='admin')); Si todo es correcto, guardamos los cambios y ya podremos pasar al siguiente punto. Página 39 de 69

40 5.3 Configuración automatizada con Maven Si no se tiene instalado maven 2.0 y se desconoce este sistema de compilación y empaquetado de aplicaciones, pasar directamente a la configuración manual de la aplicación a partir de un WAR precompilado previamente descrito en el punto siguiente. Desde la versión v2.2 de Portafirmas, el pom.xml de la aplicación incluye una serie de perfiles para compilar y empaquetar la aplicación en función del tipo de servidor de aplicaciones, base de datos o bien entorno sobre el que se va a desplegar. Esto permite generar un WAR de la aplicación totalmente configurado y personalizado para un determinado tipo de servidor de aplicaciones o base de datos con un mínimo de cambios de configuración. Veamos a continuación el perfil de configuración que tendremos que modificar y ajustarlo a nuestra configuración. Si se quiere compilar desde Eclipse importando el fuente, este debe ser Eclipse versión 3.4 o superior. Las versiones anteriores no son compatibles con la gestión de perfiles en maven Perfiles de configuración Los perfiles de configuración son los que albergan los datos de conexión de base de datos de nuestro entorno, y por tanto será lo que tendremos que adaptar antes de iniciar la compilación de la aplicación. Existen actualmente definidos los siguientes perfiles: Nombre desarrollo postgresql pruebas testing entregas Descripción Configuración del entorno de desarrollo (por defecto) Configuración para bases de datos PostgreSQL Configuración del entorno de Calidad Configuración del entorno de Testing Configuración para empaquetado con datos en limpio Estos perfiles tienen cada uno un archivo de propiedades de igual nombre ubicado en la Página 40 de 69

41 siguiente ruta dentro de la estructura maven de carpetas: /pfirmav2/src/main/filters/<perfil>.properties Deberemos por tanto editar el perfil que queramos personalizar a nuestro entorno, se recomienda escoger entregas si nuestra base de datos es Oracle o postgresql en caso de tener una base de datos PostgreSQL Personalización del perfil configuración Dentro de un fichero de configuración de un perfil, solo deberemos revisar tres parámetros esencialmente: persistence.connection.username Que contiene el nombre de usuario de conexión a base de datos. persistence.connection.password Que contiene la clave del usuario anterior. persistence.connection.url Que contiene la URL de conexión JDBC a la base de datos. Estos parámetros automáticamente se sustituirán en los archivos de configuración de Quartz o del pool de conexiones de base de datos independientemente del tipo de despliegue que definamos. Veamos unos ejemplos a continuación donde remarcamos en rojo los valores que tendrá el usuario administrador que modificar Ejemplo base de datos Oracle # Persistence Properties persistence.connection.driver.class=oracle.jdbc.driver.oracledriver persistence.connection.username=usuario persistence.connection.password=clave persistence.connection.dialect=org.hibernate.dialect.oracle9idialect persistence.cache.provider.class=org.hibernate.cache.hashtablecacheprovider persistence.connection.url=jdbc:oracle:thin:@servidor:puerto:sid persistence.show.sql=true #Quartz Properties quartz.driver=org.quartz.impl.jdbcjobstore.stdjdbcdelegate Página 41 de 69

42 #Logback Properties logger.root.level=error logger.pfirma.level=info logger.file.path=${catalina.home}/logs/${artifactid}.log Ejemplo base de datos PostgreSQL # Persistence Properties persistence.connection.driver.class=org.postgresql.driver persistence.connection.username=usuario persistence.connection.password=clave persistence.connection.dialect=org.hibernate.dialect.postgresqldialect persistence.cache.provider.class=org.hibernate.cache.hashtablecacheprovider persistence.connection.url=jdbc:postgresql://servidor:puerto/esquema persistence.show.sql=true #Quartz Properties quartz.driver=org.quartz.impl.jdbcjobstore.postgresqldelegate #Logback Properties logger.root.level=error logger.pfirma.level=info logger.file.path=${catalina.home}/logs/${artifactid}.log Perfiles servidor aplicaciones En función al tipo de servidor, existen una serie de perfiles que eliminan aquellas dependencias por librerías que vienen ya dadas por el servidor de aplicaciones en cuestión. Nombre tomcat tomcat6 Descripción Servidor Tomcat 5.X (por defecto) Servidor Tomcat 6.0 o JBoss GA Página 42 de 69

43 jboss5 Servidor JBoss GA Perfiles repositorios Por último, tendremos que indicar el repositorio de librerías maven (nexus o artifactory) para los componentes que utiliza portafirmas y que son horizontales para otros proyectos: Nombre guadaltel ceic Descripción Repositorio local de librerías del proveedor (por defecto) Repositorio público de librerías de la Junta de Andalucía Compilación y empaquetado Una vez que tenemos el perfil de configuración, servidor de aplicaciones y de repositorio podemos generar un WAR con nuestra configuración totalmente preconfigurada. Para ello tendremos que lanzar desde la carpeta que contiene el pom.xml la siguiente instrucción de maven: mvn clean install DskipTests P base,<configuracion>,<servidor>,<repositorio> El WAR de la aplicación lo tendremos en:./target/pfirmav2 2.X.Y.Z.<servidor>.war Veamos varios ejemplos: Perfil de Calidad, Servidor Tomcat 5.5.X y repositorio Guadaltel mvn clean install DskipTests P base,pruebas,tomcat,guadaltel Perfil de Testing, Servidor Tomcat 6.0.X o JBoss 4.2.3GA y repositorio público mvn clean install DskipTests P base,testing,tomcat6,ceic Perfil de Entregas, Servidor JBoss GA y repositorio público Página 43 de 69

44 mvn clean install DskipTests P base,entregas,jboss5,ceic En el caso de JBoss GA, la conexión de base de datos se realiza a través de un Pool, maven generará todo, incluso el xml de configuración de pool, pero este no va dentro del WAR, habrá que colocarlo en el servidor. Esto viene descrito más adelante en el manual, cuando se hable del despliegue de la aplicación. Este archivo solo se incluye en el WAR para este JBoss, se descarta para Tomcat5.5/6 o JBoss 4.2.3GA. Una vez que tenemos el WAR de la aplicación podemos pasar al punto principal siguiente, sobre Instalación y Configuración del Sistema, donde se describe como desplegar la aplicación en función del servidor de aplicaciones. Página 44 de 69

45 5.4 Configuración Manual En este caso partiremos de un WAR precompilado que tendremos que adaptar a la configuración de nuestro entorno. Hay un WAR por cada tipo de servidor de aplicaciones, por lo que tendremos que tomar el que corresponda, descomprimirlo en una carpeta y alterar los archivos de configuración que se detallan a continuación. Los WAR precompilados de los que se puede disponer son: Nombre WAR pfirmav2 2.X.Y.Z.tomcat.war Descripción Servidor Tomcat 5.X (por defecto) pfirmav2 2.X.Y.Z.tomcat6.war Servidor Tomcat 6.0 o JBoss pfirmav2 2.X.Y.Z.jboss5.war Servidor JBoss GA De donde X.Y.Z será la versión build correspondiente. Los datos tanto de versión así como de servidor se encuentran también en el fichero: /WEB INF/classes/version.properties Este archivo contiene la información necesaria para poder reconocer la versión y el servidor para el cual está compilada: version=v2.x.0 date=dd/mm/yyyy client=junta DE ANDALUCIA clientabreviature=ja title=portafirmas build=2.x.y.z server=<servidor> Lo ideal es descomprimir el fichero WAR y así poder realizar los cambios de configuración sobre la estructura de archivos y carpetas obtenidas. En caso de que nuestro servidor sea JBoss GA pasar directamente al punto 6, no hace falta configurar Hibernate ni Quartz dado que ya esta preconfigurado para hacer uso de pool de JBoss. Página 45 de 69

46 5.4.1 Configuración de Hibernate Dado que toda la configuración se encuentra en base de datos lo primero que debemos configurar para acceder a la misma es naturalmente la conexión a base de datos. Para ello tenemos que localizar el siguiente fichero dentro del WAR o bien dentro de la carpeta creada al descomprimir dicho archivo. /WEB INF/classes/META INF/persistence.xml Debido a que la aplicación soporta ahora mismo dos tipos de base de datos, tendremos que habilitar en el mismo las opciones correspondientes a nuestro tipo de base de datos Bases de datos Oracle Es la configuración por defecto, solo debemos comprobar que los siguientes atributos se corresponden con el archivo de configuración existente y poner los datos correctos de conexión en los elementos remarcados en rojo: <property name="hibernate.connection.driver_class" value=" oracle.jdbc.driver.oracledriver" /> <property name="hibernate.dialect" value="org.hibernate.dialect.oracle9idialect" /> <property name="hibernate.connection.url" value="jdbc:oracle:thin:@servidor:puerto:sid"/> PostgreSQL Es la configuración para el perfil PostgreSQL, solo debemos comprobar que los siguientes atributos se corresponden con el archivo de configuración existente y poner los datos correctos de conexión en los elementos remarcados en rojo: <property name="hibernate.dialect" value="org.hibernate.dialect.postgresqldialect" /> <property name="hibernate.connection.driver_class" value="org.postgresql.driver" /> <property name="hibernate.connection.url" value="jdbc:postgresql://servidor:puerto/basededatos" /> En caso contrario, y tener los valores originales de Oracle, poner los valores arriba indicados. Página 46 de 69

47 Usuario y clave Indistintamente del tipo de base de datos que tengamos, para finalizar la configuración deberemos introducir los datos del usuario o rol de conexión junto con su clave. Para ello deberemos actualizar los elementos resaltados en rojo con los datos correctos de conexión: <property name="hibernate.connection.username" value="usuario_pfirma" /> <property name="hibernate.connection.password" value="clave_pfirma" /> Tras esto ya tendremos configurada la conexión de Hibernate a la base de datos Configuración Quartz Portafirmas usa el componente Quartz. Este elemento para la gestión de hilos en los procesos asíncronos no asociados a los procesos de usuario. Ejemplo, notificaciones por correo, ejecución y reintento de acciones web, etc. Su ejecución no repercute en tiempo de espera por el usuario al ejecutarse en background. Para ello y dado que esta configurado con persistencia en el caso de caída del servidor, es necesario configurar la conexión de base de datos anterior en el fichero de configuración propio de Quartz. /WEB INF/classes/quartz.properties Al igual que antes deberemos comentar o descomentar bloques en función al tipo de base de datos, como veremos a continuación Bases de datos Oracle Nuevamente es la configuración inicial por defecto, solo debemos comprobar que los siguientes atributos se corresponden con el archivo de configuración existente y poner los datos correctos de conexión en los elementos remarcados en rojo: org.quartz.jobstore.driverdelegateclass = org.quartz.impl.jdbcjobstore.stdjdbcdelegate org.quartz.jobstore.useproperties = false org.quartz.jobstore.datasource = myds org.quartz.jobstore.tableprefix = QRTZ_ org.quartz.jobstore.isclustered = false org.quartz.datasource.myds.driver = oracle.jdbc.driver.oracledriver Página 47 de 69

48 org.quartz.datasource.myds.url = jdbc:oracle:thin:@servidor:puerto:sid PostgreSQL Es la configuración para el perfil PostgreSQL, solo debemos comprobar que los siguientes atributos se corresponden con el archivo de configuración existente y poner los datos correctos de conexión en los elementos remarcados en rojo: org.quartz.jobstore.driverdelegateclass = org.quartz.impl.jdbcjobstore.postgresqldelegate org.quartz.jobstore.useproperties = false org.quartz.jobstore.datasource = myds org.quartz.jobstore.tableprefix = QRTZ_ org.quartz.jobstore.isclustered = false org.quartz.datasource.myds.driver = org.postgresql.driver org.quartz.datasource.myds.url = jdbc:postgresql://servidor:puerto/basededatos Usuario y clave Independientemente del tipo de base de datos, solo falta ya definir el usuario o rol de conexión junto con su clave. Para ello actualizar las siguientes propiedades, lo valores resaltados en rojo por aquellos datos de conexión correctos: org.quartz.datasource.myds.user = usuario_pfirma org.quartz.datasource.myds.password = clave_pfirma El modelo de datos de Quartz es independiente de Portafirmas, si el DBA lo estima oportuno puede definirlo dentro de otro esquema de base de datos separado, teniendo cuidado de trasladar la parte del modelo de datos de Quartz a este nuevo esquema, y luego configurar en este properties el nombre del DataSource empleado o bien los datos de conexión al mismo. No se recomienda configuraciones mixtas. Una mala configuración de la conexión a base de datos puede hacer que la aplicación no arranque, por lo que habrá que prestar un especial cuidado a la configuración de este elemento. Página 48 de 69

49 5.4.3 Empaquetado Tras los cambios anteriores ya tenemos la aplicación preconfigurada, por ello podemos crear de nuevo el WAR ya con los datos actualizados usando uno de los compresores existentes ajustando el nivel de compresión a nivel normal. Se recomienda: En Guadalinex o Ubuntu, usar el compresor nativo que ya trae. En Windows se recomienda usar 7zip o Filzip. NO se recomienda usar Winrar o Winzip, para determinadas versiones de Tomcat/JBoss, estos servidores no son capaces de descomprimir el archivo resultante. Si hemos generado el fichero bien, podemos renombrar la extensión del mismo de.zip a.war y comprobar que el contenido del mismo se corresponde a una estructura similar a la siguiente: El fichero podremos renombrarlo al un nombre más sencillo y acorde para desplegar la aplicación, por ejemplo pfirmav2.war. Tomaremos el mismo y seguiremos los pasos de despligue para cada servidor indicado a continuación. Página 49 de 69

50 Página 50 de 69

51 6 INSTALACIÓN Y CONFIGURACIÓN DEL SISTEMA 6.1 Procedimiento de instalación En este punto se describe los pasos necesarios para desplegar la aplicación en función al servidor de aplicaciones del que dispongamos. Indistintamente de que hayamos hecho un empaquetado maven por perfiles o manual, en ambos casos disponemos de un war preconfigurado listo para ser desplegado en el servidor de aplicaciones. Veamos a continuación las operaciones de despliegue en función del servidor de aplicaciones Tomcat 5.X En este caso no hay que hacer nada especial, dado que el WAR ya viene con todo lo necesario para la ejecución correcta. Bastará con colocar el fichero de la aplicación en la ruta adecuada: Tomcat $TOMCAT_HOME/webapps Tomcat 6.0 o JBoss GA En este caso si hemos partido del war adecuado a esta versión (server=tomcat6), al igual que el caso anterior bastará con copiar el fichero de la aplicación a la ruta adecuada. Tomcat $TOMCAT_HOME/webapps JBoss $JBOSS_HOME/server/default/deploy La diferencia con el servidor anterior es que a nivel de aplicación hay que excluir la librería el api.jar, al traerla ya el servidor de aplicaciones embebida. Página 51 de 69

52 6.1.3 JBoss GA Para desplegar la aplicación en esta versión de servidor se deben seguir los siguientes pasos, siempre que hayamos partido de un WAR para versión de servidor jboss Creación de pool de conexiones Lo primero a tener en cuenta es la utilización de un pool de conexiones a la BBDD desde JBoss, por lo que tendremos que crearlo y configurarlo. La configuración de la conexión a la base de datos va aquí, es decir, no hace falta realizar las modificaciones que se explican en el apartado de configuración de Hibernate o Quartz. Para ello, tendremos creado el fichero pfirmav2 ds.xml en la siguiente ruta: /WEB INF/classes/pfirmav2 ds.xml Deberemos coger este archivo y colocarlo dentro del servidor de aplicaciones en la siguiente ruta: $JBOSS_HOME/server/default/deploy Si hemos hecho un empaquetado maven por perfiles ya estará todo configurado, sin embargo, en el caso de que hayamos hecho un empaquetado manual, deberemos revisar los siguientes parámetros de conexión marcados en rojo: <datasources> <local tx datasource> <jndi name>jdbc/pfirmav2ds</jndi name> <connection url>jdbc:oracle:thin:@servidor:puerto:sid</connection url> <driver class>oracle.jdbc.driver.oracledriver</driver class> <user name>usuario_pfirma</user name> <password>clave_pfirma</password> </local tx datasource> </datasources> Para el caso de PostgreSQL el datasource sería: <datasources> Página 52 de 69

53 <local tx datasource> <jndi name>jdbc/pfirmav2ds</jndi name> <connection url>jdbc:postgresql://servidor:puerto/sid</connection url> <driver class>org.postgresql.driver</driver class> <user name>usuario_pfirma</user name> <password>clave_pfirma</password> </local tx datasource> </datasources> Librerías JDBC Para que el pool funciona, las librerías JDBC de nuestra base de datos deben incluirse dentro del directorio de librerías del servidor de aplicaciones. Generalmente en: $JBOSS_HOME/server/default/lib Librería de Quartz Debido a incompatibilidad de librerías se debe actualizar la versión de Quartz de JBoss (quartz.jar). La versión que trae por defecto es la y debe ser sustituida por la versión La nueva versión debe reemplazarse por la antigua existente en este directorio: $JBOSS_HOME/common/lib Despliegue Se copia el directorio pfirmav2.war suministrado dentro de: $JBOSS_HOME/server/default/deploy Como ya se ha comentado no hace falta configurar Hibernate ni Quartz dado que ya viene preconfigurado para hacer uso del pool definido anteriormente. Página 53 de 69

54 6.2 Procedimiento de configuración Para acceder a la administración en esta primer acceso por defecto viene habilitado el modo DEBUG de la aplicación, y por tanto nos permitirá acceder por nuestro identificador y clave anteriormente introducidos al dar de alta el usuario con perfil administrador. Accederemos al menú de administración, y nos situaremos en la pestaña General General Desde aquí podemos revisar los valores globales a la aplicación, de acceso al servidor de correo, servicio de notificación, etc Parámetros A continuación vamos a ver los parámetros de configuración susceptibles de ser personalizados. SOLO modificar los aquí indicados y solo tras haber comprendido bien para que sirven y que valores pueden alojar Configuración de modos de acceso El modo de acceso por defecto en Portafirmas es la autenticación mediante certificado, sin embargo se pueden habilitar dos modos de acceso más, según sea vea necesario: Usuario y Clave: pensado para entornos de desarrollo o pruebas para facilitar el acceso a usuarios desarrolladores o probadores del sistema. NO recomendable en entornos de producción. Acceso LDAP: autenticación de usuario mediante LDAP, el sistema solicita su Página 54 de 69

55 usuario/clave de LDAP para realizar el proceso de autenticación. Previamente a poder realizar el acceso el usuario por uno de estos medios, el administrador de Portafirmas debe establecer la clave del usuario en el primero caso, o bien, definir el valor de UID para ligar la autenticación LDAP con el usuario existente en Portafirmas. Los valores a revisar son los siguientes: Nombre LOGIN.DEBUG LOGIN.LDAP LOGIN.LDAP.URL USUARIO.LDAP.IDATRIBUTO LOGIN.LDAP.IDENTIFICADOR LOGIN.LDAP.BASEDN LOGIN.LDAP.SEARCHBASE Descripción Acceso en modo DEBUG, que permite el acceso con usuario y clave de base de datos. Valores S o N. Indica si se permite la autenticación mediante LDAP. Valores S o N. URL de conexión a servidor LDAP, en caso de ser por SSL recordar importar el certificado al almacén de certificados. Nombre del atributo de usuario en servidor LDAP que liga con el usuario de Portafirmas, generalmente sera el propio UID pero puede ser cualquier otro que queramos de los existentes. Expresión para buscar los datos del usuario. Ejemplo: (uid=$1) Expresión para autenticar al usuario. Ejemplo:uid=$1,o=cice,o=empleados,o=juntadeandalucia,c=e s Expresión para la búsqueda en un usuario, generalmente tendrá el mismo valor que el BASEDN:uid=$1,o=cice,o=empleados,o=juntadeandalucia,c =es Para ver más ejemplos de configuración de conexión a LDAP revisar el manual de Administración, donde vienen ejemplos para OpenLDap o ActiveDirectory o como definir autenticaciones en varias ramas (personal, externos, etc) Configuración de avisos por correo Portafirmas incorpora distintos puntos donde notifica por correo a los usuarios de los distintos eventos que suceden el sistema. Llegada de nuevas peticiones pendientes, lectura, firma, devolución de las mismas, o inclusión de nuevos comentarios a una petición. La notificaciones solo llegarán a aquellas direcciones de correo que defina el usuario como Página 55 de 69

56 susceptibles de recibir avisos, pudiendo por tanto desactivar la misma a conveniencia. Página 56 de 69

57 Los valores a revisar son los siguientes: Nombre NOTIFICACION.CORREO NOTIFICACION.CORREO.NOMBRE Descripción Permite habilitar o deshabilitar el envío de avisos por correo, tanto al receptor o al remitente. Valores S o N. Nombre a mostrar del remitente NOTIFICACION.CORREO.REMITENTE NOTIFICACION.SMTP.SERVIDOR NOTIFICACION.SMTP.PUERTO NOTIFICACION.CORREO.AUTH NOTIFICACION.CORREO.USUARIO NOTIFICACION.CORREO.CLAVE Cuenta de correo que será remitente de todos los avisos por correo. Nombre del servicio SMTP de correo. Puerto de escucha del servidor SMTP de correo. Generalmente es el 25. Indica si el servidor SMTP requiere autenticación. Valores S o N. Usuario de correo para autenticación SMTP. Clave del usuario de correo para autenticación SMTP Configuración de informes de firma A continuación vamos a ver los valores a revisar para la personalización de los informes de firma. Los valores a revisar son los siguientes: Nombre Descripción INFORME.TIPO Tipo de informe de firma, valores de 1 a 4. INFORME.CLAVE.3DES INFORME.URL.VERIFICACION Clave 3DES para el cifrado de código de documento firmado. URL de verificación de Verifirma Configuración proxy Dado que Portafirmas puede acceder vía HTTP/HTTPS 1 a otros servidores de aplicaciones 1 Cualquier conexión SSL requiere que se haya importado al almacén de certificados la clave pública del servidor al cual se conecta para que se autorice el acceso a dicha URL. Página 57 de 69

58 para lanzar las acciones web que se le pasan las aplicaciones para ser avisadas de los distintos cambios de estado, en determinados entornos es necesario definir un servidor proxy. Página 58 de 69

59 Los valores a revisar son los siguientes: Nombre Descripción PROXY Utilización de proxy. Valores S o N. PROXY.SERVIDOR PROXY.PUERTO PROXY.USUARIO PROXY.CLAVE Maquina proxy conexiones http/https Puerto de escucha servidor proxy Usuario servidor proxy. En caso de no haber, dejar en blanco. Clave del usuario del servidor proxy. Esta configuración proxy solo afecta para el acceso a las acciones web de terceras aplicaciones, no para el acceso a los servicios de firma. Esta comunicación debe ser directa por temas de rendimiento y seguridad de las informaciones. Si por requerimientos externos se obliga pasar por proxy para acceder a los servicios hay que añadir los siguientes parámetros de configuración a la JVM del servidor de aplicaciones: Dhttp.proxyHost=<servidorProxy> Dhttp.proxyPort=<puertoDeEscucha> Dhttp.proxyUser=<usuarioProxy> Dhttp.proxyPassword=<ClaveUsuarioProxy> Dhttp.nonProxyHosts=<localhost X.X.X.X> Configuración de Custodia Portafirmas V2 admite trabajar con distintos tipos de custodia, permitiendo incluso que si es necesario se pueda implementar un par de interfaces para adaptar el sistema de custodia a los requisitos internos de cada instalación. Nativamente Portafirmas ofrece tres implementaciones, en base de datos, alfresco y sobre sistema de ficheros. Los cambios en este valor solo son aplicables para nuevas peticiones y ficheros que no se hayan incorporado con anterioridad. Nombre CUSTODIA.TIPO CUSTODIA.FICHERO.RUTA CUSTODIA.FICHERO.INPUTCLASS Descripción Tipo de almacenamiento para contenido binario, dos posibles valores, BLOB o bien FICHERO. Ruta de almacenamiento para la implementación de almacenamiento sobre sistema de ficheros. Clase que implementa la interfaz de almacenamiento de ficheros a una ruta. Dejar el Página 59 de 69

60 valor cargado inicialmente. CUSTODIA.FICHERO.OUTPUTCLASS Clase que implementa la descarga de documentos de una ruta de ficheros. Dejar el valor cargado inicialmente. Para conocer más información revisar el manual de administración, o bien para implementar nuevas interfaces revisar a la documentación para desarrolladores. Página 60 de 69

61 Tipos de documentos Estos son los tipos de documentos globales a toda la aplicación. Debemos tener al menos algún tipo de documento habilitado Aplicaciones Desde aquí podemos administrar la aplicaciones, esto se detalla más exhaustivamente en el manual de administración, ahora solo nos centraremos en comprobar que tenemos una aplicación llamada PFIRMA. Si no existe, la daremos de alta y la asociaremos a la configuración del servidor principal Servidores Ahora revisaremos la configuración por defecto del servidor principal. Página 61 de 69

62 Página 62 de 69

63 Si no disponemos de firma deberemos de solicitar una configuración de acceso a sus servicios, en el caso de Administración Pública, deberemos rellenar un formulario publicado en su web, en el cual a parte de una serie de informaciones nos preguntarán las siguientes necesidades: Custodia de documentos: No es necesaria. Sellado de tiempo o Timestamp: queda a libre elección, si bien recomendada si se va firmar documentos donde la fecha de firma sea importante. Tipo de autorización de acceso a los servicios: Autorización mediante usuario/clave, es la más recomendable a ser la menos costosa computacionalmente. Aumentar a la basada en certificados digitales si el entorno de ejecución es no seguro. Módulo de validación: Autenticación nativa mediante servicios web. Modulo firma: Firma de servidor. Firma de usuario, dos fases y firma en bloque. La aplicación soporta ambos tipos. Hay que usar la primera en caso de multifirma masiva o la segunda en caso de hacer uso de la firma en bloque. Validación de firma. Revisar los procedimientos de Alta de una configuración en función al servidor del que vayamos a hacer uso Parámetros Los parámetros a revisar son aquellos de acceso al es por tanto necesario Página 63 de 69