Nombre del Proyecto. Portafirmas. Fecha 04/07/2017. Versión. Versión 3.1. Tipo de documento. Manual de Instalación

Fecha

04/07/2017

Versión

Versión 3.1

Tipo de documento

Manual de Instalación

1.INTRODUCCIÓN...7

1.1.Objeto...7

1.2.Alcance...7

2.DESCRIPCIÓN DEL SISTEMA...8

2.1.Antecedentes y descripción funcional del sistema...8

2.2.Nuevas funcionalidades...8

2.3.Componentes fundamentales...9

2.4.Relación con otros sistemas...10

3.Recursos Hardware...11

3.1.Servidores...11

3.2.Estaciones cliente...11

3.3.Conectividad...11

3.4.Restricciones...12

4.RECURSOS SOFTWARE...13

4.1.Matriz de certificación...13

4.2.Restricciones técnicas del sistema...13

4.3.Requisitos de otros sistemas...14

5.INSTALACIÓN Y CONFIGURACIÓN DEL SOFTWARE BASE...15

5.1.Instalación sobre Oracle...15

5.1.1.Procedimiento primera instalación...15

5.1.1.1.Tablespaces...15

5.1.1.2.Usuario propietario...15

5.1.1.2.1.Permisos...15

5.1.1.3.Usuario de aplicación...15

5.1.1.4.Creación del modelo de datos...16

5.1.1.5.Carga inicial de datos...17

5.1.1.6.Alta de usuario administrador...17

5.1.2.Procedimiento de actualización...19

5.1.2.1.2.Actualización del modelo de datos...19

5.1.2.1.3.Vuelta atrás del modelo de datos...19

5.1.3.Obsolescencia Interfaz PLSQL...20

5.2.Instalación sobre PostgreSQL...21

5.2.1.Procedimiento primera instalación...21

5.2.1.1.Creación del rol de conexión...21

5.2.1.2.Tablespaces...21

5.2.1.3.Creación del esquema...23

5.2.1.4.Creación del modelo de datos...23

5.2.1.5.Carga inicial de datos...25

5.2.1.6.Alta de usuario administrador...25

5.2.2.Procedimiento de actualización...27

5.2.2.1.1.Actualización...27

5.2.2.1.2.Actualización del modelo de datos...27

5.2.2.1.3.Vuelta atrás del modelo de datos...27

6.CONFIGURACIÓN DEL SISTEMA...28

6.1.Configuración automatizada con Maven...28

6.1.1.Perfiles de configuración...28

6.1.1.1.Personalización del perfil configuración...29

6.1.2.Perfiles servidor aplicaciones...29

6.1.3.Perfiles empaquetado de la aplicación web...29

6.1.4.Perfiles plataforma de autenticación, firma y validación...30

6.1.5.Perfiles proveedor de usuarios y Single Sign On...30

6.1.6.Perfiles content-manager...30

6.1.7.Perfiles conversión automática de documentos a PDF...30

6.2.Configuración Manual...31

6.2.1.Configuración de Hibernate...31

6.2.2.Configuración Quartz (SQLServer)...32

6.2.3.Empaquetado...33

7.COMPILACIÓN DEL SISTEMA...34

7.1.Ejemplos de compilación y empaquetado...34

8.INSTALACIÓN DEL SISTEMA...35

8.1.Requisitos previos...35

8.2.Procedimiento de instalación...35

8.2.1.Wildfly...35

8.2.1.1.Creación del DataSource para Portafirmas...35

8.2.1.2.Creación del DataSource para Quartz...36

8.2.1.3.Driver de datasource...38 8.2.1.3.1.Oracle...38 8.2.1.3.2.PostgreSQL...38 8.2.1.3.3.SQLServer...38 8.2.1.4.Librerías JDBC...38 8.2.1.5.Despliegue...39

9.VERIFICACIÓN DEL PROCESO DE INSTALACIÓN...40

10.ANEXOS...41

10.1.Guía Rápida de Configuración...41

10.1.1.General...41

10.1.1.1.Login - Configuración de modos de acceso...41

10.1.1.2.Notificaciones - Configuración de avisos por correo...43

10.1.1.3.Configuración de informes de firma...44

10.1.1.4.Configuración proxy...44 10.1.1.5.Configuración de Custodia...46 10.1.1.6.Tipos de documentos...46

10.1.2.Aplicaciones...47

10.1.3.Servidores...48

10.1.3.1.3.Configuración de seguridad...51

10.1.4.Configuración de implementaciones...52

10.1.4.1.Proveedor de usuarios y Single Sign On...52

10.1.4.1.1.Implementación Principal basada en SPNEGO...52

10.1.4.1.2.Implementación Principal basada en JOSSO...52

10.1.4.2.Conversión automática de documentos a PDF...53

10.1.4.2.1.Servicio OpenOffice...53

10.1.4.2.2.Servicio AMAP-PDFConverter...53

10.2.BinarySecurityToken: Habilitar proveedor BC...55

10.3.Habilitar comunicaciones bajo SSL/HTTPs...56

10.4.Ajustes del pool de conexiones de base de datos...60

10.5.Ajustes en la configuración de memoria de la JVM...61

10.6.Configuración de la Zona Horaria...62

10.7.Configuración de archivos de log...63

10.8.Configuración de juego de caracteres...64

10.9.Tiempo de sesión de usuario...64

10.10.Configuración de Content Manager como custodia...65

10.10.1.Generación de war con maven...65

10.10.2.Configuración de properties...65

10.10.3.Activar Content como custodia y generador de informes desde Administración...67

10.11.Configuración de certificado de Portafirmas...68

10.11.1.Creación...68

10.11.2.Cambio de clave en administración...69

10.12.Restringir acceso a los servicios web...72

10.13.Instalación de servicio OpenOffice...73

1.

INTRODUCCIÓN

1.1.

Objeto

El objetivo del presente documento es servir de guía en la instalación o actualización a Portafirmas v3. Bien sea una instalación desde cero o bien proceda de una versión v2.9 o inferior. En éste último caso será necesario a realizar el proceso de actualización de Portafirmas v2 hasta llegar al menos a la versión v2.9. Toda la instalación está 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, nomenclatura de tablespaces, o bien, a valores más reales a sus entornos de funcionamiento.

El documento tiene dos bloques diferenciados. Primera instalación en un esquema en limpio, o bien el proceso de actualización de un esquema de Portafirmas v2.9 a Portafirmas v3.

1.2.

Alcance

El presente documento está dirigido a los siguientes perfiles de usuario:

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

2.

DESCRIPCIÓN DEL SISTEMA

2.1.

Antecedentes y descripción funcional del sistema

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

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.

La versión V3 de la herramienta surge como necesidad de actualización tecnológica de la plataforma, así como adaptar los interfaces a los nuevos estánderes en el diseño de aplicaciones web (diseño adaptativo), como consecuencia de que un número creciente de usuarios hace uso a diario de su móvil para temas no solo personales sino en su puesto de trabajo.

2.2.

Nuevas funcionalidades

versiones (sin activar la vista de compatibilidad) y optimización en el renderizado de HTML gracias a las posibilidades que ofrecen las nuevas versiones de frameworks JSF.

• Nuevo diseño de interfaz “Responsive”, se adapta automáticamente al dispositivo para visualizar las informaciones sin necesidad de que el usuario tenga que hacer nada.

• Temas visuales aún más personalizables desde la administración, a nivel global, o a nivel particular de cada usuario. Elección de fondos fijos, fotográficos, colores de botones, fuentes y todo de forma dinámica.

• Vista a nivel de bandeja, todo se pueda hacer directamente desde la bandeja, sin requerir una pantalla de petición.

• Eliminación total de los applets, firma exclusivamente mediante Autofirma. Incluso en el cifrado local de certificados para la funcionalidad de firma mediante certificados custodiados en servidor, ahora el certificado/pin se cifra de forma asimétrica en local por Javascript y viaja ya cifrado hasta el servidor. • Migración de todos los procesos de firma a firma trifásica, lo cual permite firmar archivos de cualquier

tamaño.

• Conversión automática de documentos a PDF. Posibilidad de configurar, activar y o desactivar la conversión automática de documentos no PDFs a este formato para así disponer de un formato homogéneo de documentos dentro de la plataforma y generar informes de ellos indistintamente del formato en el que lleguen.

• Puede funcionar al mismo tiempo con una instalación de Portafirmas v2.9, de forma que el paso a la nueva versión se pueda hacer de forma escalonada.

• Nueva versión de la aplicación de verificación, se han aplicado los mismos criterios, arquitectura y tecnología que en Portafirmas v3. Incorpora las mismas funcionalidades que Verifirma v2.

• Nuevo diseño “Resposive” en Verifirma, adaptable automáticamente al tamaño de la pantalla.

• Se ha cambiado la navegación de pantallas para que funcione a modo de asistente “paso a paso” de cara al usuario final.

• Ofrece servicios web para una nueva aplicación móvil de verificación de informes de firma capturando con la cámara directamente el código QR de los informes, sin necesidad de introducir nada ni acceder a la web.

2.3.

Componentes fundamentales

Módulo Descripción

Web Portafirmas Portal Web de Portafirmas electrónico Servicios Web V1 Antiguos servicios web rpc/literal Servicios Web V2 Nuevos servicios web document/literal

Cliente de firma Android Cliente de firma para el sistema operativo Android Cliente de firma iOS Cliente de firma para el sistema operativo iOS

2.4.

Relación con otros sistemas

Sistema Relación Tipo

Plataforma de autenticación, firma y validación

- @firma 5.5.X ó 6.1.X, uso de servicios nativos de autenticación,

firma en dos fases, verificación y OASIS-DSS. Obligatorio

SMTP 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 por protocolo CMIS. Opcional

Content Manager Custodia sobre Content Manager según ENI. Opcional

3.

Recursos Hardware

3.1.

Servidores

Servidor de Aplicaciones

Dato Valor mínimo Valor recomendado

Procesador 1 Procesador 2 Núcleos 64 bits 1 Procesador 4 Núcleos 64 bits

Memoria RAM1 _{2 GB 4 GB}

Tamaño Almacenamiento2 _{2 - 5GB 10 - 20GB}

Sistema Operativo Linux o Windows (64 bits) Linux o Windows (64 bits)

3.2.

Estaciones cliente

• Disponer de una instalación local de Autofirma. Se puede descargar de: http://firmaelectronica.gob.es/Home/Descargas.html

• Un navegador compatible con la invocación por protocolo de Autofirma. Se puede comprobar en: https://validador.guadaltel.es/

• En el caso de dispositivo móvil, los soportados por el cliente de firma iOS y Android. • Certificado personal de usuario admitido por la plataforma @firma.

Para acceder a la información relacionada con @firma acceder al Área Técnica de @firma o bien en la web Centro de Transferencias Tecnológicas.

http://administracionelectronica.gob.es/

3.3.

Conectividad

Conectividad con los servicios web de firma de la plataforma de autenticación, firma y validación. Para el caso particular de @firma:

• Una instancia local de @firma Federado. • Plataforma @firma de Administración Pública.

• Instancia @firma publicada vía red S.A.R.A para las administraciones públicas.

1 Cantidad de memoria en el servidor poder dedicar un 60-70% al servidor de aplicaciones.

2 Para despliegue de la aplicación, temporales y archivos de log o traza. No se incluye en esta estimación el espacio de custodia para documentos y firmas.

3.4.

Restricciones

Restricción Detalle

4.

RECURSOS SOFTWARE

4.1.

Matriz de certificación

Certificado JBoss Wildfly 9.0 JBoss Wildfly 10.1

Oracle JDK 1.7.0 64 bits Ok No

Oracle JDK 1.8.0 64 bits Ok Ok

Relación de servidores testados, no implica que no pueda funcionar en otros. El requisito es que el servidor de aplicaciones soporte JEE6/7.

4.2.

Restricciones técnicas del sistema

Elemento Descripción

Sistema operativo • Linux

• Windows

Servidor de aplicaciones • JBoss Wildfly 9.0

• JBoss Wildfly 10.1

Servidor de base de datos • Oracle 10g, 11g ó 12c

• PostgreSQL 8.X o 9.X. • SQL Server 2012

Compilador • Maven 3.2.1

JVM • Oracle JDK 1.7.0 64 bits

4.3.

Requisitos de otros sistemas

Plataforma de autenticación, firma y validación (obligatorio)

Descripción Plataforma de Autenticación, Firma y Validación.

Funcionalidad utilizada Servicios Web SOAP de Autenticación, Firma y Validación. • Interfaz Servicios Nativos

• Interfaz OASIS-DSS

Requisito formal Conectividad con los servicios web de firma de la plataforma de firma: - @firma

• Una instancia local de @firma Federado. • Plataforma @firma de Administración Pública. • Instancia @firma publicada vía red S.A.R.A para las

administraciones públicas.

Requisito técnico Para el caso de @firma las versiones soportadas son 5.5.X ó 6.1.X. El sellado de tiempo es opcional a decisión de cada instalación si bien recomendable para firma longeva.

Requisito de comunicación Visibilidad a nivel de red con los servicios de firma de @firma.

Alfresco (opcional)

Descripción Gestor Documental.

Funcionalidad utilizada Servicios CMIS Rest/Atom para el almacenamiento de documentos. Requisito formal Disponer de un usuario para poder conectar y guardar datos en el mismo.

Requisito técnico Alfresco 4.X o superior.

Requisito de comunicación Visibilidad a nivel de red con los servicios web de gestión documental.

Content Manager (opcional)

Descripción Gestor Documental centralizado según ENI.

Funcionalidad utilizada Servicios para el almacenamiento de documentos

Requisito formal Disponer de los datos para poder conectar y guardar documentos en el mismo. Dependiendo de la implementación de Content pueden ser datos de conexión a base de datos, CMIS o G·EDE.

Requisito técnico Alfresco o base de datos de versiones soportadas por Content (revisar documentación de Content Manager a tal efecto).

5.

INSTALACIÓN Y CONFIGURACIÓN DEL SOFTWARE BASE

5.1.

Instalación sobre Oracle

Distinguimos dos casos, procedimiento de primera instalación o actualización desde una v2.9. 5.1.1. 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 del sistema.

5.1.1.1. 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. • TS_PFIRMA_TEMP: El tamaño inicial 64MB.

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.

5.1.1.2. 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> 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 quota unlimited on TS_PFIRMA_TEMP;

5.1.1.2.1. Permisos

Los permisos que necesita el usuario propietario del esquema son: grant create session, alter session to PFIRMAMG;

5.1.1.3. 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:

default tablespace TS_PFIRMA_DATOS temporary tablespace temp;

Los permisos iniciales para este usuario serán: grant create session, alter session 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 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 interfaz de servicios web publicada, NUNCA accediendo directamente al modelo de datos.

5.1.1.4. 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, lo que serían tablas, índices, restricciones y secuencias. Para ello hay que lanzar el siguiente script de base de datos:

/pfirmav3-parent/src/main/database/oracle/create/script_create.sql

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.

5.1.1.5. 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:

/pfirmav3-parent/src/main/database/oracle/create/script_data.sql

Al final del mismo se realiza el commit. 5.1.1.6. 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) Values

(PF_S_USU.NEXTVAL, :DNI, :NOMBRE, :APELL_1, :APELL_2, 'USUARIO', 'S');

El valor en el campo C_IDENTIFICADOR debe estar en mayúsculas, por tanto el valor introducido en la variable :DNI debe introducirse en mayúsculas.

Luego le asignaremos una clave:

Insert into PF_USUARIOS_PARAMETRO

(X_USUARIO_PARAMETRO, T_VALOR, PAR_X_PARAMETRO, USU_X_USUARIO) Values

:CLAVE,

(select X_PARAMETRO from pf_parametros where C_PARAMETRO='USUARIO.PASSWORD'), (select X_USUARIO from pf_usuarios where c_identificador=:DNI));

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;

5.1.2. Procedimiento de actualización

Como ya se ha indicado antes, Portafirmas v3 se puede simultanear en ejecución con la versión V2.9 al mismo tiempo, de forma que así el paso de versión puede ser escalonado por grupo de usuarios e ir pasando a la nueva versión poco a poco. Se reduce así el impacto de la actualización, así como la vuelta atrás basta con acceder a la versión anterior.

En este caso partimos desde una instalación de Portafirmas v2.9 que ya contiene una serie de informaciones (configuraciones, usuarios, peticiones, documentos, firmas, etc), y queremos mantener en la nueva versión. En caso de no disponer de una v2.9, se deben aplicar primero los procedimientos de actualización necesarios hasta alcanzar dicha versión siguiendo los manuales correspondientes. Y solo una vez actualizado y probado dicha versión, actualizar a v3.

A continuación vamos a ver una descripción del proceso así como una serie de consejos.

5.1.2.1.1. Actualización

La actualización del modelo de datos se realiza en pocos minutos y se resume en dos pasos:

• Actualización del modelo de datos para añadir un campo a la tabla de PF_ETIQUETAS y un set específico de tablas de QUARTZ para ejecución de los procesos en Background para Portafirmas v3 para no entrar en conflicto con las de v2.

• Carga de la configuración específica para v3, nuevos parámetros particulares en la configuración de v3 que no afectan a la ejecución de v2, pero son necesarios para la ejecución de la misma.

Se recomienda realizar la actualización primero en un entorno de desarrollo o pruebas, siendo altamente recomendable hacerlo sobre una copia de datos de producción, para así hacer primero pruebas de rendimiento con un volumen de datos igual al de producción.

5.1.2.1.2. Actualización del modelo de datos

Para ello debemos lanzar el primer script, el que añade el nuevo campo y las tablas de quartz para v3: /pfirmav3-parent/src/main/database/oracle/upgrade/script_upgrade.sql

Si los tablespaces son distintos a los establecidos por defecto, revisar el script de actualización del modelo para indicar correctamente los tablespaces definidos en nuestro esquema.

Una vez hecho, el siguiente paso es cargar la configuración específica de v3: /pfirmav3-parent/src/main/database/oracle/upgrade/script_data.sql

Tras lanzarlo ya tendremos el modelo de datos V3 completamente definido.

5.1.2.1.3. Vuelta atrás del modelo de datos

Si hemos tenido un problema en la actualización a v3 y queremos volver atrás a Portafirmas v2.9 podemos hacerlo lanzando el siguiente script:

/pfirmav3-parent/src/main/database/oracle/rollback/script_rollback_upgrade.sql

Las informaciones generadas desde v3 seguirán siendo compatibles con v2, eliminado el script el nuevo campo, las tablas de quartz así como la configuración específica de v3.

5.1.3. Obsolescencia Interfaz PLSQL

Portafirmas v3 deja de soportar nativo PLSQL, esto implica que tanto la API PLSQL como las acciones de retorno PLSQL no son soportadas. Aunque funcione a priori la API PLSQL de v2, se recomienda eliminar una vez migrado a v3, dado que deja de tener soporte sobre la misma.

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

5.2.1.1. 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 “pfirma”, 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 pfirma LOGIN

ENCRYPTED PASSWORD '****************************************' NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;

Es recomendable probar el usuario recién creado antes de continuar. 5.2.1.2. Tablespaces

Para nuestra instancia de base de datos tenemos que crear los siguientes tablespaces:

• TS_PFIRMA_INDICES.

• TS_PFIRMA_DATOS.

• TS_PFIRMA_TEMP.

mkdir $HOME/Trabajo/BD/TS_PFIRMA_DATOS mkdir $HOME/Trabajo/BD/TS_PFIRMA_INDICES mkdir $HOME/Trabajo/BD/TS_PFIRMA_TEMP

sudo chown postgres:postgres $HOME/Trabajo/BD/TS_PFIRMA_*

La creación de los tablespace's se debe realizar con el usuario de sistema de PostgreSQL, “postgres”.

Tras esto, creamos los dos tablespaces:

Las instrucciones SQL equivalentes serían: CREATE TABLESPACE "TS_PFIRMA_DATOS" OWNER pfirma

LOCATION '/home/XXX/Trabajo/BD/TS_PFIRMA_DATOS'; CREATE TABLESPACE "TS_PFIRMA_INDICES"

OWNER pfirma

LOCATION '/home/XXX/Trabajo/BD/TS_PFIRMA_INDICES'; CREATE TABLESPACE "TS_PFIRMA_TEMP"

OWNER pfirma

LOCATION '/home/XXX/Trabajo/BD/TS_PFIRMA_TEMP';

En PostgreSQL no se puede definir un tablespace para una columna específica. El almacenamiento de documentos binarios en caso de escoger la custodia en base de datos se hará sobre la propia tabla, y por tanto el tablespace TS_PFIRMA_DATOS. Esto puede repercutir en el

rendimiento.

Es recomendable en este tipo de base de datos usar implementaciones de custodia en sistema de archivos, unidad de red o bien gestor documental para así no sobrecargar los tablespaces destinados inicialmente para información alfanumérica.

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

La sentencia SQL equivalente: CREATE SCHEMA pfirma AUTHORIZATION pfirma;

5.2.1.4. 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:

/pfirmav3-parent/src/main/database/postgresql/create/script_create.sql

Lo cargamos y le damos a ejecutar:

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.

5.2.1.5. 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:

/pfirmav3-parent/src/main/database/postgresql/create/script_data.sql

Una vez cargado, le damos a ejecutar:

Revisar luego mirando el contenido de las tablas que se han cargado los datos. 5.2.1.6. 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

(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'));

5.2.2. Procedimiento de actualización

Como ya se ha indicado antes, Portafirmas v3 se puede simultanear en ejecución con la versión V2.9 al mismo tiempo, de forma que así el paso de versión puede ser escalonado por grupo de usuarios e ir pasando a la nueva versión poco a poco. Se reduce así el impacto de la actualización, así como la vuelta atrás basta con acceder a la versión anterior.

En este caso partimos desde una instalación de Portafirmas v2.9 que ya contiene una serie de informaciones (configuraciones, usuarios, peticiones, documentos, firmas, etc), y queremos mantener en la nueva versión. En caso de no disponer de una v2.9, se deben aplicar primero los procedimientos de actualización necesarios hasta alcanzar dicha versión siguiendo los manuales correspondientes. Y solo una vez actualizado y probado dicha versión, actualizar a v3.

A continuación vamos a ver una descripción del proceso así como una serie de consejos.

5.2.2.1.1. Actualización

La actualización del modelo de datos se realiza en pocos minutos y se resume en dos pasos:

• Actualización del modelo de datos para añadir un campo a la tabla de PF_ETIQUETAS y un set específico de tablas de QUARTZ para ejecución de los procesos en Background para Portafirmas v3 para no entrar en conflicto con las de v2.

• Carga de la configuración específica para v3, nuevos parámetros particulares en la configuración de v3 que no afectan a la ejecución de v2, pero son necesarios para la ejecución de la misma.

Se recomienda realizar la actualización primero en un entorno de desarrollo o pruebas, siendo altamente recomendable hacerlo sobre una copia de datos de producción, para así hacer primero pruebas de rendimiento con un volumen de datos igual al de producción.

5.2.2.1.2. Actualización del modelo de datos

Para ello debemos lanzar el primer script, el que añade el nuevo campo y las tablas de quartz para v3: /pfirmav3-parent/src/main/database/postgresql/upgrade/script_upgrade.sql

Si los tablespaces son distintos a los establecidos por defecto, revisar el script de actualización del modelo para indicar correctamente los tablespaces definidos en nuestro esquema.

Una vez hecho, el siguiente paso es cargar la configuración específica de v3: /pfirmav3-parent/src/main/database/postgresql/upgrade/script_data.sql

Tras lanzarlo ya tendremos el modelo de datos V3 completamente definido.

5.2.2.1.3. Vuelta atrás del modelo de datos

Si hemos tenido un problema en la actualización a v3 y queremos volver atrás a Portafirmas v2.9 podemos hacerlo lanzando el siguiente script:

/pfirmav3-parent/src/main/database/postgresql/rollback/script_rollback_upgrade.sql

Las informaciones generadas desde v3 seguirán siendo compatibles con v2, eliminado el script el nuevo campo, las tablas de quartz así como la configuración específica de v3.

6.

CONFIGURACIÓN DEL SISTEMA

6.1.

Configuración automatizada con Maven

Si no se tiene instalado maven 3.2.1 y 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.

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 4.4 o superior.

6.1.1. 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 Descripción

desarrollo Configuración del entorno de desarrollo (por defecto)

pruebas Configuración del entorno de Calidad

entregas Configuración para empaquetado con datos en limpio

demos Configuración del entorno de Demos

Estos perfiles tienen cada uno un archivo de propiedades de igual nombre ubicado en la siguiente ruta dentro de la estructura maven de carpetas:

/pfirmav3-parent/src/main/filters/profiles/<perfil>.properties

Deberemos por tanto editar el perfil que queramos personalizar a nuestro entorno, se recomienda escoger “entregas”, por defecto configurado con una URL JDBC Oracle.

6.1.1.1. Personalización del perfil configuración

En el caso de que nuestro motor de base de no sea Oracle, deberemos revisar el dialecto de Hibernate para que sea el correspondiente a nuestro motor de base de datos. En el propio archivo viene indicado un ejemplo de cada uno de los motores soportados.

# Oracle 10g: org.hibernate.dialect.Oracle10gDialect # SQLSever: org.hibernate.dialect.SQLServer2008Dialect # Postgresql: org.hibernate.dialect.PostgreSQLDialect persistence.connection.dialect=org.hibernate.dialect.Oracle10gDialect #Quartz Properties # Oracle 10g: org.quartz.impl.jdbcjobstore.StdJDBCDelegate # SQLSever: org.quartz.impl.jdbcjobstore.MSSQLDelegate # Postgresql: org.quartz.impl.jdbcjobstore.StdJDBCDelegate quartz.driver=org.quartz.impl.jdbcjobstore.StdJDBCDelegate

También en este archivo se puede indicar el nivel de detalle que queremos en la generación de los archivos de log, así como la ubicación de los mismos.

#Logback Properties log4j.rootLogger=ERROR log4j.logger.org.portafirmas=INFO

log4j.file.path=$RUTA_LOG/${artifactId}.log

Este es la única configuración que hay que personalizar por instalación, el resto de valores viene ya preconfigurado en perfiles preestablecidos de motor de base de datos, servidor de aplicaciones y repositorio con lo que solo hay que indicar las características de nuestro entorno en el comando de compilación.

Veamos el resto de configuraciones disponibles. 6.1.2. 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 Descripción

wildfly9 Servidores JBoss Wildfly 9.0

wildfly10 Servidores JBoss Wildfly 10.1

6.1.3. Perfiles empaquetado de la aplicación web

En función al empaquetado que se vaya a hacer de la aplicación.

Nombre Descripción

6.1.4. Perfiles plataforma de autenticación, firma y validación

En función al tipo de plataforma, se incluyen unas librerías u otras para el acceso a los servicios de estas. Estos perfiles no son excluyentes por lo que se pueden tener más de uno.

Nombre Descripción

afirma5 Plataforma @firma 5.5 o superior (6.X)

La disponibilidad de una plataforma de autenticación, firma y validación dependerá del entorno final de ejecución de la aplicación.

6.1.5. Perfiles proveedor de usuarios y Single Sign On

Implementaciones de proveedores de usuarios y de Single Sign On.

Nombre Descripción

principal Integración con el sistema Single Sign On SPNEGO

josso Integración con el sistema Single Sign On JOSSO

La disponibilidad de una plataforma de proveedor de usuarios dependerá del entorno final de ejecución de la aplicación.

6.1.6. Perfiles content-manager

Podemos definir varias implementaciones internas de Content Manager:

Nombre Descripción

contentmanager-gede Internamente guarda los documentos G·EDE

contentmanager-dbcmds Internamente guarda los documentos base de datos

6.1.7. Perfiles conversión automática de documentos a PDF

Implementaciones disponibles para la conversión automática de documentos a PDF desde la pantalla de redacción.

Nombre Descripción

openoffice-pdfconverter Implementación para un servidor OpenOffice local o centralizado

6.2.

Configuración Manual

En este caso partiremos de un WAR precompilado que tendremos que adaptar a la configuración de nuestro entorno. Tendremos que tomar el WAR, descomprimirlo en una carpeta y alterar los archivos de configuración que se detallan a continuación.

El WAR precompilado es:

Nombre WAR Servidor Motor Base de Datos JDK

pfirmav3.war WildFly 9.0_{WildFly 10.1} Oracle 10g,11g ó 12c PostgreSQL 8 ó 9 SQLServer 2008 ó 2012

1.7 1.8

Los datos concretos de compilación se encuentran en el archivo: /WEB-INF/classes/version_info.properties

Este archivo contiene la información necesaria para poder reconocer la versión, base de datos y servidor de aplicaciones:

Version=${3.X.Y} date=dd/MM/yyyy title=PORTAFIRMAS V3

Lo ideal es descomprimir el fichero WAR y así poder realizar los cambios de configuración sobre la estructura de archivos y carpetas obtenidas.

6.2.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. El fichero de configuración se encuentra dentro del jar pfirmav3-persistence-3.X.Y.jar en la ruta:

/META-INF/persistence.xml

6.2.1.1. Bases de datos 6.2.1.1.1. Oracle

Se debe establecer el dialecto de hibernate para Oracle (valor por defecto en la compilación): <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect" />

6.2.1.1.2. PostgreSQL

Se debe establecer el dialecto de hibernate para PostgreSQL:

6.2.1.1.3. SQLServer

Se debe establecer el dialecto de hibernate para SQLServer:

<property name="hibernate.dialect" value="org.hibernate.dialect.SQLServer2008Dialect" />

6.2.2. Configuración Quartz (SQLServer)

Portafirmas usa el componente Quartz para la gestión de hilos en los procesos asíncronos no asociados a los procesos de usuario. Por ejemplo para avisos 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 está 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 para el caso de SQLServer. Dicho fichero se encuentra dentro del WAR o bien dentro de la carpeta creada al descomprimir dicho archivo. El fichero de configuración se encuentra dentro del jar pfirmav3-core-X.Y.Z.jar en la ruta

/classes/quartz.properties

Sólo será necesario editar la propiedad siguiente para el caso de SQLServer:

org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.MSSQLDelegate

La configuración por defecto soporta Oracle y PostgreSQL:

org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate

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.

6.2.3. Empaquetado

Tras los cambios anteriores ya tenemos la aplicación preconfigurada, por ello podemos crear de nuevo el WAR/EAR ya con los datos actualizados usando uno de los compresores existentes ajustando el nivel de compresión a nivel normal.

Se recomienda:

• En Ubuntu o Linux, usar el compresor nativo que ya trae. • En Windows se recomienda usar Winrar, 7zip o Filzip.

Debemos emplear el formato ZIP en el proceso de compresión.

Si hemos generado el fichero bien, podemos renombrar la extensión del mismo de .zip a .war/.ear 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 “pfirmav3.war”. Este nombre, obviando la extensión .war, será la ruta dentro del servidor de aplicaciones a la que deberemos acceder para trabajar con la aplicación. Tomaremos este archivo y seguiremos los pasos de despliegue para cada servidor indicados en el apartado correspondiente.

7.

COMPILACIÓN DEL SISTEMA

Una vez que tenemos definidos el perfil de configuración, motor de base de datos, servidor de aplicaciones y el repositorio podemos generar un WAR con nuestra configuración totalmente preconfigurada.

Para ello tendremos que lanzar desde la carpeta pfirmav3-parent que contiene el pom.xml la siguiente instrucción de maven:

mvn clean install -DskipTests -P <configuracion>,<servidor>,<plataforma_firma>,<empaquetado> ,<content-manager>,<conversor-pdf>

El WAR de la aplicación lo tendremos en: ./target/pfirmav3-3.X.Y.war

7.1.

Ejemplos de compilación y empaquetado

Veamos varios ejemplos:

Perfil de Entregas, Servidor WildFly 10.1, plataforma @firma, Content Manager G·EDE y conversor OpenOffice:

mvn clean install -DskipTests -P entregas,wildfly10,afirma5,war,contentmanager-gede,openoffice-pdfconverter

En los casos de Jboss WildFly, la conexión de base de datos se realiza a través de un Pool y viene descrito más adelante en el manual, cuando se hable del despliegue de la aplicación.

Una vez que tenemos el WAR de la aplicación podemos pasar al punto principal siguiente, Instalación del Sistema, donde se describe como desplegar la aplicación en función del servidor de aplicaciones.

8.

INSTALACIÓN DEL SISTEMA

En este punto se describen los pasos necesarios para desplegar la aplicación en función al servidor de aplicaciones del que dispongamos.

8.1.

Requisitos previos

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 con la configuración y librerías necesarias para conectar a la base de datos.

Portafirmas lleva toda la configuración en la base de datos, por tanto es importante haber resuelto correctamente la conexión a la misma para poder realizar una instalación en el servidor de aplicaciones.

8.2.

Procedimiento de instalación

Veamos a continuación las operaciones de despliegue en función del servidor de aplicaciones. 8.2.1. Wildfly

Para desplegar la aplicación en esta versión de servidor se deben seguir los siguientes pasos, siempre que hayamos partido de un artefacto para versión de servidor “wildfly”. Vamos a crear dos datasources en el servidor de aplicaciones, uno para el modelo de Portafirmas (JTA) y otro para el modelo de Quartz (no JTA).

8.2.1.1. Creación del DataSource para Portafirmas El nombre JNDI del datasource a crear es:

java:jboss/datasources/PFIRMADS

Para crear un datasource en el servidor de aplicaciones tenemos que seguir los siguientes pasos: • Abrir el fichero de configuración de WildFly:

$RUTA_WILDFLY$/standalone/configuration/standalone.xml

• Localizar la etiqueta de “datasources”: <subsystem xmlns="urn:jboss:domain:datasources:1.0">

<datasources> … </datasources> </subsystem>

• Introducir el datasource necesario para la aplicación, revisando los valores marcados en rojo: <datasource jta="true" jndi-name="java:jboss/datasources/PFIRMADS" pool-name="PFIRMADS" enabled="true" use-java-context="true" use-ccm="true">

<connection-url>cadena_conexion</connection-url> <driver>driver</driver>

<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation> <pool>

<min-pool-size>5</min-pool-size> <max-pool-size>100</max-pool-size> <prefill>true</prefill>

<use-strict-min>false</use-strict-min>

<flush-strategy>FailingConnectionOnly</flush-strategy> </pool>

<security>

<user-name>usuario_pfirma</user-name> <password>clave_pfirma</password> </security>

<validation>

<check-valid-connection-sql>sql_check</check-valid-connection-sql> </validation>

<statement>

<prepared-statement-cache-size>32</prepared-statement-cache-size> <share-prepared-statements>true</share-prepared-statements> </statement>

</datasource>

Tenemos que sustituir los valores de los parámetros en rojo de nuestro entorno:

Parámetro Descripción

cadena_conexion

Cadena de conexión a la base de datos: - Oracle: jdbc:oracle:thin:@host:port:sid - PostgreSQL: jdbc:postgresql://hostname:port/database - SQLServer: jdbc:sqlserver://host:port;databaseName=dbName;instanceName=insName

driver Nombre del driver definido en el fichero de configuración (oracle, postgresql, _sqlserver)

usuario_pfirma Usuario de conexión a base de datos

clave_pfirma Clave del usuario de conexión a base de datos sql_check SQL para comprobación de conexión correcta

Este pool de base de datos tiene por defecto 5 conexiones de mínimo y 100 de máximo. Estos valores también pueden ser adaptados en función a la carga de trabajo del servidor de aplicaciones. Los parámetros recomendados de configuración de estos valores son inicialmente:

<min-pool-size>5</min-pool-size> <max-pool-size>100</max-pool-size>

8.2.1.2. Creación del DataSource para Quartz

Además debemos crear un datasource para la gestión interna de Quartz. El nombre JNDI del datasource a crear es:

java:jboss/datasources/PFIRMADS_QUARTZ

Siguiendo los mismos pasos que en el punto anterior llegamos a lo siguiente (reemplazar los valores en rojo):

<datasource jta="false" jndi-name="java:jboss/datasources/PFIRMADS_QUARTZ" pool-name="PFIRMADS_QUARTZ" enabled="true" use-java-context="true" use-ccm="true"> <connection-url>cadena_conexion</connection-url>

<driver>driver</driver>

<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation> <pool>

<min-pool-size>5</min-pool-size> <max-pool-size>100</max-pool-size> <prefill>true</prefill>

<use-strict-min>false</use-strict-min>

<flush-strategy>FailingConnectionOnly</flush-strategy> </pool>

<security>

<user-name>usuario_pfirma</user-name> <password>clave_pfirma</password> </security>

<validation>

<check-valid-connection-sql>sql_check</check-valid-connection-sql> </validation>

<statement>

<prepared-statement-cache-size>32</prepared-statement-cache-size> <share-prepared-statements>true</share-prepared-statements> </statement>

</datasource>

Tenemos que sustituir los valores de los parámetros en rojo de nuestro entorno:

Parámetro Descripción

cadena_conexion

Cadena de conexión a la base de datos: - Oracle: jdbc:oracle:thin:@host:port:sid - PostgreSQL: jdbc:postgresql://hostname:port/database - SQLServer: jdbc:sqlserver://host:port;databaseName=dbName;instanceName=insName

driver Nombre del driver definido en el fichero de configuración (oracle, postgresql, _sqlserver)

usuario_pfirma Usuario de conexión a base de datos

clave_pfirma Clave del usuario de conexión a base de datos sql_check SQL para comprobación de conexión correcta

Este pool de base de datos tiene por defecto 5 conexiones de mínimo y 100 de máximo. Estos valores también pueden ser adaptados en función a la carga de trabajo del servidor de aplicaciones. Los parámetros recomendados de configuración de estos valores son inicialmente:

<min-pool-size>5</min-pool-size> <max-pool-size>100</max-pool-size>

Debemos recordar que este datasource es no JTA, por lo que se debe tener en cuenta en su definición (jta="false") a diferencia del datasource anterior de Portafirmas que sí es JTA.

8.2.1.3. Driver de datasource

En el datasource anterior hacemos referencia a un driver que no viene por defecto en el servidor de aplicaciones, por lo que lo añadimos a continuación del datasource y dentro de la etiqueta <drivers>:

8.2.1.3.1. Oracle

<drivers>

<driver name="oracle" module="com.oracle">

<xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class> </driver>

</drivers>

Este driver hace referencia a un módulo nuevo llamado “com.oracle” que tampoco existe en el servidor. Lo daremos de alta en el siguiente apartado junto con el resto de librerías que se deben incluir en el servidor.

8.2.1.3.2. PostgreSQL

<drivers>

<driver name="postgresql" module="org.postgresql"> <driver-class>org.postgresql.Driver</driver-class> </driver>

</drivers>

Este driver hace referencia a un módulo nuevo llamado “com.oracle” que tampoco existe en el servidor. Lo daremos de alta en el siguiente apartado junto con el resto de librerías que se deben incluir en el servidor.

8.2.1.3.3. SQLServer

<drivers>

<driver name="sqlserver2012" module="com.microsoft">

<driver-class>com.microsoft.sqlserver.jdbc.SQLServerDriver</driver-class> </driver>

</drivers>

Este driver hace referencia a un módulo nuevo llamado “com.microsoft” que tampoco existe en el servidor. Lo daremos de alta en el siguiente apartado junto con el resto de librerías que se deben incluir en el servidor.

8.2.1.4. Librerías JDBC

A continuación la relación de librerías que hay que incluir al servidor de aplicaciones dependiendo del driver que hace uso el datasource (sólo la que corresponda):

Módulo Descripción

org.postgresql Se añade la librería de jdbc para PostgreSQL.

com.microsoft Se añade la librería de jdbc para Microsoft SQLServer.

Wildfly provee de un sistema de carga de librerías o módulos. Estos módulos están formados por un xml (module.xml) que define el nombre del módulo y los jars que lo componen.

En la tabla anterior se han descrito los nombres de los módulos que se deben añadir o modificar sin entrar en detalles de los jars que llevan dentro. Estos módulos se encuentran en:

$RUTA_WILDFLY$/modules/

Cada módulo se encuentran dentro del directorio al que hace referencia su nombre, por ejemplo, en $RUTA_WILDFLY$/modules/com/oracle tendremos la librería con el driver jdbc para Oracle.

8.2.1.5. Despliegue

Una vez realizados los pasos anteriores, y asegurándonos de que el servidor de aplicaciones WildFly se encuentra parado, sólo nos queda copiar el war a la carpeta de despliegue:

$RUTA_WILDFLY$/standalone/deployments

9.

VERIFICACIÓN DEL PROCESO DE INSTALACIÓN

La mejor forma de comprobar el funcionamiento de la aplicación, es acceder a la misma mediante el usuario de administración creado.

Para ello accederemos desde un navegador a la siguiente url: http://servidor:puerto/pfirmav3

Esto nos mostrará la siguiente pantalla:

Si le damos al botón “Acceder mediante usuario y contraseña (DEBUG)”, deberemos acceder a la aplicación, y al módulo de administrador con el usuario que hayamos definido como administrador.

Si el contexto no existe, o no está arrancado, revisar el archivo de log para ver la causa del error en el arranque y conexión a la base de datos.

10.

ANEXOS

En el manual de administración de la aplicación se describe la configuración completa de la misma, si bien a continuación mostramos una guía rápida de configuración repasando únicamente los elementos esenciales para el funcionamiento de la aplicación.

10.1.

Guía Rápida de Configuración

Para acceder a la administración en este 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 se nos mostrará la pantalla General de parámetros.

10.1.1. General

Desde aquí podemos revisar los valores globales a la aplicación, de acceso al servidor de correo, servicio de notificación, etc.

A continuación vamos a ver los parámetros de configuración susceptibles de ser personalizados. SOLO modificar los

aquí

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 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 Descripción

Activar login en modo debug (Usuario y clave)

Acceso en modo DEBUG, que permite el acceso con usuario y clave de base de datos.

Activar login por LDAP Indica si se permite la autenticación mediante LDAP. Al activarlo se habilitan el resto de campos a rellenar.

URL de conexión al servidor LDAP URL de conexión a servidor LDAP, en caso de ser por SSL recordar importar el certificado al almacén de certificados.

Patrón de autenticación LDAP BASEDN

Expresión para autenticar al usuario. Ejemplo: uid=$1,ou=Interno,ou=Personal,dc=guadaltel,dc=es

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. Patrón de búsqueda de usuario Expresión para buscar los datos del usuario. Ejemplo:

(uid=$1) Patrón DN para la búsqueda del

usuario

Expresión para la búsqueda en un usuario, generalmente tendrá el mismo valor que el LDAP BASEDN. Ejemplo:

uid=$1,ou=Interno,ou=Personal,dc=guadaltel,dc=es Nombre del atributo de LDAP que

vincula con el usuario Portafirmas. Es el atributo que sirve para relacionar el usuario de LDAP con el usuario de Portafirmas. Ejemplo: mail

Una vez rellenos, podemos probar desde esta pantalla la configuración definida para comprobar el correcto funcionamiento.

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

10.1.1.2. Notificaciones - Configuración de avisos por correo

Portafirmas incorpora distintos puntos donde avisa 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.

Los avisos solo llegarán a aquellas direcciones de correo que defina el usuario como susceptibles de recibir avisos, pudiendo por tanto desactivar la misma a conveniencia.

Los valores a revisar son los siguientes:

Nombre Descripción

Activar notificaciones por correo electrónico Permite habilitar o deshabilitar el envío de avisos por correo, tanto al receptor o al remitente. En caso de activarla, se habilitan el resto de valores.

Dirección del servidor SMTP Nombre del servicio SMTP de correo.

Puerto del servidor SMTP Puerto de escucha del servidor SMTP de correo.

Generalmente es el 25.

Nombre del remitente en las notificaciones de correo electrónico

Nombre a mostrar del remitente

Dirección del remitente en notificaciones de correo electrónico

Cuenta de correo que será remitente de todos los avisos por correo. Se recomienda que sea una cuenta desatendida (no-response).

Autenticación en servidor de correo electrónico Indica si el servidor SMTP requiere autenticación. Si la activamos nos pedirá que introduzcamos el usuario y clave. Securización del canal para notificaciones de

correo electrónico

Indica el tipo se seguridad del canal. Los posibles valores pueden ser: plana (sin seguridad), SSL o TLS

Usuario para autenticar en servidor de correo electrónico

Contraseña para autenticar en servidor de

correo electrónico Clave del usuario de correo para autenticación SMTP.

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

Tipo de informe de firmas Tipo de informe de firma, valores de 1 a 9. Además tenemos la posibilidad de:

- Ninguno: útil, por ejemplo, para implantaciones que realizan firmas PDF y no usan el informe

- Content Manager: delega la generación a dicho framework (debe estar activa dicha custodia)

URL de Verifirma URL de verificación de Verifirma. Aparecerá en los informes

de firma si corresponde. No se debe incluir la / final ya que aparecería duplicada.

Clave 3DES para cifrar el hash de Verifirma Clave 3DES para el cifrado de código de documento firmado.

Tipo de código de verificación segura (CSV) El CSV que se utilizará.

Los demás valores son opciones de personalización del informe. 10.1.1.4. Configuración proxy

Dado que Portafirmas puede acceder vía HTTP/HTTPS3 _{a otros servidores de aplicaciones para lanzar las}

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

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.

Los valores a revisar son los siguientes:

Nombre Descripción

Activar el uso de servidor proxy para

conexiones http o https. Utilización de proxy.

Servidor proxy Maquina proxy conexiones http/https

Puerto de la máquina proxy Puerto de escucha servidor proxy

Activar autenticación en servidor proxy Activa o no la autenticación mediante usuario y clave con el servidor proxy.

Usuario para autenticar en servidor proxy. Usuario servidor proxy.

Clave para autenticar en servidor proxy 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 de @firma, 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>

10.1.1.5. Configuración de Custodia

Portafirmas V3 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.

De forma nativa Portafirmas ofrece varias implementaciones, en base de datos, alfresco, sobre sistema de ficheros, Content Manager, unidad CIFS y custodia compuesta de dos anteriores (Multicustodia). La configuración inicial por defecto es BLOB. Los cambios en este valor solo son aplicables para nuevas peticiones y ficheros que no se hayan incorporado con anterioridad. 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.

10.1.1.6. 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. Por defecto se cargan los tipos GENERICO, REMISION y FACTURAE-RECEPCION.

10.1.2. 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”.

10.1.3. Servidores

Ahora revisaremos la configuración por defecto del servidor principal.

Si no disponemos de servidor de firma propio deberemos de solicitar una configuración de acceso a sus servicios, en el caso de @firma de Administración Pública o de @firma en Red SARA del MINHAP. Deberemos rellenar un formulario publicado en su web, en el cual a parte de una serie de informaciones nos preguntarán las siguientes necesidades generales:

• IP Origen: Dirección IP dentro de red SARA.

• Responsable de Sistemas: Para que puedan dirigirse a él en caso de que haya cambios a nivel de red o problemas de servicio.

• Entorno: Marcar ambos, Desarrollo y Producción.

• Volumen de transacciones mensuales: Los valores estimados para una instalación normal serían ◦ Desarrollo: 500

• Volumen máximo de transacciones por minuto: ◦ Desarrollo: 2

◦ Producción: 10 • Aplicación

◦ Nombre de Aplicación: PFIRMA

◦ Descripción de la Aplicación: Portafirmas electrónico

◦ Organismo y Responsable: Nombre y responsable para la aplicación en concreto.

◦ Lista de servicios: validación de firmas y certificados, upgrade de firmas para incluir sellado de tiempo.

◦ URL donde se encuentran los servicios: Url prevista donde va a estar la aplicación. • Peticiones WS

◦ Formato de firma de respuesta: XMLDSignature (Firma XML Básica) ◦ Política de Validación: Política Crítica

◦ Clave pública: Incluir la clave pública del certificado que se usará para la firma de peticiones SOAP. Certificado en vigor de una entidad certificadora reconocida.

• Peticiones OCSP

◦ No se usa, no rellenar.

Una vez relleno remitir a la dirección de alta de @firma.

En el caso de hacer uso de otra plataforma distinta de firma, seguir los protocolos y solicitudes definidas en las mismas.

10.1.3.1. Parámetros

Los parámetros a revisar son aquellos de acceso al servidor @firma, es por tanto necesario tener a mano los datos de acceso al mismo.

Dentro de la configuración, los parámetros a revisar son:

Nombre Descripción

Aplicación Nombre de la aplicación en @firma

Aunque hayamos indicado un valor, por lo general, en la respuesta a la solicitud de alta se indica el identificador final dado de alta en la plataforma, que será el que debamos configurar en la aplicación.

10.1.3.1.1. Configuración de firma

En este apartado se define los tipos u formatos de firma. Por defecto se carga una configuración base recomendada, revisar el manual de administración para ver que configuración o configuraciones son más óptimas para nuestro entorno.

10.1.3.1.2. Configuración de servidor