Versión 3.2.0

Transcripción

Versión 3.2.0

Tabla de contenido
1. Introducción
i. Control de cambios
2. Requisitos
3. Servicios externos
4. Kit de instalación
5. Base de datos
6. Instalación
i. Actualización del backend
ii. Actualización de licencia
7. Configuración
i. documents.xml
ii. config.properties
iii. Certificado de firma
i. Generar CSR
8. Primer acceso
9. Histórico de cambios y versiones
i. Backend
i. Cambios de configuración
ii. App iOS
iii. App Android
10. Glosario
1
Manual de instalación
Información dirigida a perfiles técnicos y con solvencia en la instalación y despliegues de aplicaciones JEE.
Si lo desea puede descargar este manual en pdf aquí.
Kit de Instalación
Guía de configuración
1. Crear y configurar las aplicaciones Documents iOS y Documents Android en documents
2. Asignar plantillas de ejemplo a nuestro usuario en documents
3. Instalar las aplicaciones en los dispositivos móviles, configurarla para acceder a nuestro backend y probar las
aplicaciones.
Introducción
2
Control de cambios
Esta documentación técnica está sujeta a modificaciones diarias, y alguna información o configuración avanzada podría
no estar reflejada. Consulte en cualquier caso con el equipo de soporte técnico.
Revisión
Fecha
Actualización
12-julio-2016
Últimas versiones liberadas
Servicios
Versión
Backend
3.2.7
App iOS
3.2.2
App Android
3.2.1
DB Documents (backend)
0.0.63
Biometric signature verifier
1.4.1
Últimos cambios
Fecha
Cambio
19-may-16
Versión inicial del manual de instalación
27-may-16
Actualización del proveedor de Java
30-jun-16
Añadidos apartados Actualización del backend e Histórico de cambios
04-jul-16
Añadida versión 3.2.6
11-jul-16
Añadida versión 3.2.7
12-jul-16
Nuevo capítulo 5.2 Actualización de licencia.
Controldecambios
3
Requisitos
¿Qué voy a necesitar para la instalación?
Servidor de aplicaciones JEE Tomcat 7.
Java 1.7.x de Oracle.
Base de Datos (Oracle o Postgre).
¿Qué dimensionamiento le dedico?
Se tomará como ejemplo una instalación en un mismo servidor de aplicaciones. En caso de optar por una instalación
en varios servidores, o instalación en clúster, consultar con el soporte técnico de viafirma las opciones recomendadas
para cada caso.
RAM: 8GB
Micro: recomendado, 2 micros de 6 núcleos cada uno; a 2Ghz.
Disco: 20 GB (1)
Logs: estimado 1GB por cada millón de operaciones (1)
Custodia: variable según peso y número de documentos firmados. Estimado inicial 20 GB.
Logs de auditoría: estimado 1GB por cada millón de operaciones. Estimado incial 20 GB.
(1): los logs incluyen configuración de rotación, por lo que la optimización de estos logs podrá definirse por el
administrador del sistema en función a las políticas de espacio en disco deseadas.
Requisitos de la máquina
Es necesario que la máquina en la que se va a desplegar viafirma documents tenga el locale es_ES.UTF-8, para evitar
problemas de encoding.
Por ejemplo en ubuntu sería:
$apt-get install language-pack-es-base
$update-locale LANG=es_ES.UTF-8
Requisitos
4
Servicios externos
¿Qué servicios externos voy a necesitar?
Un certificado digital para la firma de documentos
Una clave pública para el cifrado de datos biométricos
Servicio de timestamping RFC3161 (ofrecido por una TSA - Timestamping Authority)
Servidor SMTP para el envío de correos.
Restricción de Conexiones Externas
Salidas con proxies
Si se va a necesitar salir por un proxy, es necesario informar los datos de conexión para inlcuirlos en la configuración
específica de conexión de cada componente.
Es importante detectar antes de la instalación si existen mecanismos internos que puedan alterar las cabeceras http en
las comunicaciones de red, pues el sistema implementa varios mecanismos de securización y autenticación, como
OAuth, sensible a este tipo de comportamiento y que haría inviable la instalación del servicio.
Validación de Certificados Digitales
Se necesita verificar las fuentes de validación de las Entidades de Certificación (CA - Certificate Authority) que hayan
emitido los certificados con los que se va a trabajar.
Sólo en el caso de que el servidor no tenga libre salida a internet, habrá que autorizar específicamente la lista de
fuentes de validación que se deseen, como mínimo, al servicio OCSP, CRL o endpoint en el que poder verficar el root
ca. Por ejemplo:
http://ocsp.gse.com.co
http://crl.gse.com.co/crl_sub001_ac_gse.crl
http://crl1.gse.com.co/crl_sub001_ac_gse.crl
http://certs.gse.com.co/sub/crt_sub01_ac_gse.crt
Autoridad de Tiempo (TSA)
Viafirma documents necesita consumir los servicios de tiempo con las TSA contratadas o autorizadas por el cliente.
Sólo en el caso de que el servidor donde esté instalado viafirma documents no tenga libre salida a internet, habrá que
autorizar específicamente la lista de autoridades de tiempo que se deseen. Por ejemplo:
http://tsu2.camerfirma.com:8884/tsc
Serviciosexternos
5
Validación de Licencia
En el arranque del servidor se realiza una comprobación remota de la validez de la licencia instalada. Para ello es
necesaria tener salida a las siguientes URLs:
https://services.viafirma.com/licensemanager/
Proveedores de Notificaciones Push
Se consumirán las APIs de los dos proveedores de notificaciones push, Google y Apple, para lo que hay que autorizar
las siguientes salidas:
Google Cloud Messaging (GCM) (1)
https://android.googleapis.com/gcm/send
Apple Push Notificaction (APN) (2)
Producción: gateway.push.apple.com, port 2195
Desarrollo (sandbox): gateway.sandbox.push.apple.com, port 2195
(1) Documentación oficial de google: http://developer.android.com/google/gcm/http.html
(2) Documentación oficial de apple:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/
CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW1
Serviciosexternos
6
Kit de instalación
Se hará entrega de un kit de instalación con los siguientes recursos:
documents.war
documents.xml
documents-home
config.properties
logback.xml
hazelcast.xml
cacerts.jks
trusted_cacerts.jks
sql
oracle
00_services_clear.sql
01_services_tablas.sql
02_services_secuence.sql
04_services_insert.sql
05_services_indexes.sql
06_services_views.sql
postgres
00_services_clear.sql
01_services_tablas.sql
02_services_constraints.sql
03_services_secuence.sql
04_services_insert.sql
05_services_indexes.sql
06_services_views.sql
documents_es.pdf
ojdbc6.jar Driver de oracle
postgresql-9.3-1102.jdbc41.jar Driver de postgresql
Adicionalmente se hará entrega de la licencia de la aplicación.
Kitdeinstalación
7
Base de datos
Tablas
Nombre de la tabla
Descripción
Tamaño aprox.
CONFIGURATION
Configuración de la aplicación
< 1MB
ROLE_USER_APP
Relación de usuarios y roles. Al menos un
registro por cada usuario.
< 1MB
USER_APP_GROUP
Relación de usuarios y grupos. Dependerá del
empleo de grupos.
< 1MB
USER_APP_TEMPLATE
Relación de usuarios y plantillas.
< 1MB
VD_APLICATION
Aplicaciones
< 1MB
VD_COORDINATES
Coordinada de los mensajes. Dependerá del
número de mensajes.
1MB por cada 10.000
mensajes
VD_DEVICE
Dispositivos
1MB por cada 1.000
dispositivos
VD_GROUP
Grupos
< 1MB
VD_MESSAGE
Mensajes
1MB por cada 500
mensajes
VD_MESSAGE_AUDITORY
Auditoría de mensajes
1MB por cada 1000
mensajes
VD_ROLE
Roles
< 1MB
VD_ROLE_ACTION
Acciones de cada rol
< 1MB
VD_TEMPLATE
Plantillas
1MB por cada 10
plantillas. El número de
plantillas suele ser
reducido.
VD_TEMPORAL_DATA
Tabla temporal para el almacenamiento de pdf e
imagenes para componer el documento firmado.
1 MB por cada 10
registros.
VD_TOKEN
Tokens de los usuarios
< 1MB
VD_TRANSFER_JOB
Tranferencia de mensajes. Sólo se emplea en
entornos con transferencia personalizada de
mensajes. Requiere un desarrollo a medida
1MB cada 3.000
registros
VD_USER_APP
Usuarios
1MB por cada 2.000
usuarios
¿Qué tablas son paramétricas y cuáles transaccionales?
Paramétricas:
Basededatos
8
CONFIGURATION
VD_APLICATION
VD_COORDINATES
VD_GROUP
VD_ROLE
VD_ROLE_ACTION
VD_SCHEDULED_TASK
VD_TEMPLATE
VD_USER_APP
Transaccionales:
ROLE_USER_APP
USER_APP_APLICATION
USER_APP_GROUP
USER_APP_TEMPLATE
VD_DEVICE
VD_MESSAGE
VD_MESSAGE_AUDITORY
VD_NOTIFICATION
VD_PROPERTY
VD_TEMPORAL_DATA
VD_TOKEN
VD_TRANSFER_JOB
¿Qué tablas tienen una mayor carga de trabajo?
Las tablas que tienen una mayor carga de trabajo (insert, update) son:
VD_COORDINATES
VD_DEVICE
VD_MESSAGE
VD_MESSAGE_AUDITORY
VD_TEMPORAL_DATA
VD_TOKEN
VD_USER_APP
Basededatos
9
Instalación
1. Crear esquemas de base de datos y ejecutar los scripts correspondientes a la base de datos empleada.
2. Descargar tomcat
3. Modificar Catalina.sh en el tomcat
CATALINA_OPTS="-Dfile.encoding=UTF-8-Dcom.sun.management.jmxremote
-Djava.awt.headless=true-Xmx1512M-server-Xms512M-XX:NewSize=128m
-XX:MaxNewSize=256m-XX:SurvivorRatio=5-XX:TargetSurvivorRatio=30
-XX:PermSize=128m-XX:MaxPermSize=256m-Xincgc-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing-XX:+CMSParallelRemarkEnabled-XX:+UseParNewGC
-XX:+UseTLAB-XX:+CMSPermGenSweepingEnabled-XX:+CMSClassUnloadingEnabled
-Dsun.jnu.encoding=ISO-8859-15-Djava.net.preferIPv4Stack=true"
CATALINA_PID=/tmp/tomcat.pid
4. Configurar los accesos a base de datos y el directorio del DOCUMENTS_HOME en el fichero documents.xml.
5. Copiar el fichero documents.xml modificado en el punto anterior al directorio conf/Catalina/localhost del tomcat.
6. Crear la carpeta definida en la variable DOCUMENTS_HOME del contexto.
7. Copiar en la carpeta DOCUMENTS_HOME el contenido de la carpeta documents-home del kit de instalación.
8. Configurar los ficheros config.properties, logback.xml y hazelcast.xml con los valores correspondientes a nuestra
instalación.
9. Copiar el driver correspondiente a la base de datos seleccionada a la carpeta lib del tomcat.
10. Copiar documents.war al directorio webapp de tomcat
11. Iniciar tomcat y acceder a la aplicación desde http://localhost:8080/documents
12. La primera vez que accederemos la aplicación detectará que no tiene instalada una licencia valida por lo que
redirigirá a la url http://localhost:8080/documents/license donde se debe incorporar la licencia suministrada.
Entornos con SSL
Para entornos con SSL se recomienda la activación de preservación de la url de usuario.
Por ejemplo en apache:
proxypreserverhostson
Instalación
10
Procedimiento de actualización
El proceso de actualización del backend se compone de 3 pasos:
Actualización de la base de datos
Actualización de la configuración
Despliegue del nuevo war
Actualización de la base de datos
Cada versión del backend va asociada a una versión de la base de datos concreta. Puede consultar las versiones de
base de datos asociadas a las diferentes versiones del backend en el histórico de versiones del backend.
Para actualizar de una versión a otra del backend con diferentes versiones de la base de datos, será necesario ejecutar
todos los scripts intermedios.
Así por ejemplo para actualizar de una versión 3.0.2 del backend (que tiene versión 0.0.57 de la base de datos) a la
versión 3.2.0 (que tiene versión 0.0.62 de la base de datos) deberan ejecutarse los scripts de actualización
correspondientes de las versiones:
upgrade_0.0.57_to_0.0.58.sql
Los scripts de actualización serán proporcionados por su proveedor al que deberá indicar la versión actual del backend,
la nueva versión y el proveedor de base de datos (oracle o postgresql).
Actualización de la configuración
Cada versión del backend puede tener o no asociados cambios de configuración. Los cuales puede consultarlos en el
histórico de cambios de configuración del backend.
Para actualizar de una versión a otra del backend será necesario ejecutar todos los cambios de configuración
intermedios.
Así por ejemplo para actualizar de una versión 3.0.2 del backend a la versión 3.2.0 serán necesarios realizar los
cambios de configuración asociados a las versión 3.1.3.
Externalizar los ficheros de configuración (config.properties, hazelcast.xml y logback.xml) a la carpeta definida
como DOCUMENTS_HOME en el contexto.
Actualizacióndelbackend
11
Despliegue del nuevo war
Copiar documents.war al directorio webapp de tomcat.
Actualizacióndelbackend
12
Actualización de Licencia
Para actualizar una licencia existente acceder al siguiente recurso:
http://<documents-home>/documents/license
El acceso se debe hacer con un usuario con perfil súper-administrador, y se podrá incluir la nueva licencia recibida.
Actualizacióndelicencia
13
Configuración
Ficheros de configuración:
documents.xml
config.properties
logback.xml
hazelcast.xml
Configuración
14
documents.xml
En este fichero se configurará el acceso a base de datos, CDI (Context And Dependency Injection) y la ruta física de la
carpeta documents-home.
Base de datos
Ejemplo oracle:
<Resourceauth="Container"driverClassName="oracle.jdbc.driver.OracleDriver"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"maxActive="100"
maxIdle="30"maxWait="10000"name="jdbc/default_manager"
type="javax.sql.DataSource"url="jdbc:oracle:thin:@localhost:1521:ORCL"
username="documents"password="xxxxxxx"/>
Ejemplo postgresql
<Resourceauth="Container"driverClassName="org.postgresql.Driver"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"maxActive="100"
maxIdle="30"maxWait="10000"name="jdbc/default_manager"
type="javax.sql.DataSource"url="jdbc:postgresql://localhost:5432/documents"
username="documents"password="xxxxxxx"/>
CDI (Context And Dependency Injection)
<Resourceauth="Container"description="RequiredforCDIinTomcat"
factory="org.jboss.weld.resources.ManagerObjectFactory"name="BeanManager"
type="javax.enterprise.inject.spi.BeanManager"/>
Documents-home
Es necesario definir una carpeta sobre la cual la aplicación debe tener permisos de lectura y escritura. En esta carpeta
es donde deben ubicarse los ficheros de configuración config.properties, logback.xml y hazelcast.xml. Además en ella
se ubicarán los ficheros de custodia y auditoria.
Para entornos montados sobre un clúster será necesario que esta carpeta sea accesible desde todas las máquinas.
<Environmentdescription="Documentshome"name="DOCUMENTS_HOME"
override="false"type="java.lang.String"value="/home/viafirma/documents-home"/>
documents.xml
15
documents.xml
16
config.properties
Este es el fichero de configuración propio de la aplicación. A continuación se definirán las diferentes opciones de
configuración:
URL_PROTOCOL
Indica el protocolo de la url de la aplicación. Los posibles valores son http o https.
Obligatorio
AUTHENTICATOR_CHAIN
Implementación del sistema de control de acceso utilizado.
No obligatorio
Valor por defecto: com.viafirma.mobile.services.security.DatabaseAuthenticator
MAIL_HOST_NAME
Host del servidor de correo electrónico
Obligatorio
MAIL_SMTP_USER
Usuario del servidor de correo electrónico
Obligatorio
MAIL_SMTP_PASS
Contraseña del servidor de correo electrónico
Obligatorio
MAIL_FROM
Remitente de los correos
Obligatorio
MAIL_SSL
Indica si la conexión con el servidor de correo electrónico es mediante SSL. Los posibles valores son true o false
No obligatorio
Valor por defecto: false
CREATE_TEMPLATE_EXAMPLES
Creación de plantillas de ejemplo. Los posibles valores son true o false.
No obligatorio
config.properties
17
Valor por defecto: false
REPOSITORIO_IMPL
Implementación del sistema de gestión de ficheros disponible.
No obligatorio
Valor por defecto: org.hanuman.framework.external.repository.ManagerFileRepositorySimpleImpl
OAUTH_REQUEST_MAX_AGE
Tiempo en milisegundos, si se supera esta diferencia de tiempo entre la hora de la petición y la hora del servidor se
rechaza la petición a la capa de servicios REST. Toma el valor 0 en caso de no querer aplicar esta restricción.
No obligatorio
Valor por defecto: 0
OAUTH_EXPIRE_TOKEN_MINUTES
Tiempo en minutos que indica la caducidad de tokens de acceso al API, un token caduca cuando pasan los
minutos indicados en esta variable sin ningún acceso al API REST.
No obligatorio
SYSTEM_STATUS_ERROR_THREAD_TIMER_DELAY
Tiempo en milisegundos que indica el tiempo de demora desde el inicio del sistema, con el que se empieza a
comprobar el estado del sistema.
No obligatorio
SYSTEM_STATUS_ERROR_THREAD_TIMER_PERIOD
Tiempo en milisegundos que indica cada cuanto tiempo se comprueba el estado del sistema.
No obligatorio
TRUSTED_JKS_PATH
Acceso al KeyStore que contiene las claves públicas de las CA en las que confia la plataforma.
Obligatorio
TRUSTED_JKS_PASSWORD
Contraseña del KeyStore que contiene las claves públicas de las CA en las que confia la plataforma.
Obligatorio
SIGNATURE_JKS_PATH
Acceso al KeyStore que contiene los certificados utilizados por la plataforma para la firma de documentos,
config.properties
18
evidencias o cifrado de datos.
Obligatorio
SIGNATURE_JKS_PASSWORD
Contraseña del KeyStore que contiene los certificados utilizados por la plataforma para la firma de documentos,
evidencias o cifrado de datos.
Obligatorio
DEFAULT_CUSTODY_CODE
Código de cutodia de documentos firmados.
No obligatorio desde la versión 3.2.0.
Valor por defecto: CKRD
DEFAULT_ENCRYPTION_KEY_ALIAS
Alias de la clave pública de cifrado de datos biométricos existente en KeyStore de firma.
Obligatorio
DEFAULT_CERTIFICATE_ALIAS
Alias del certificado utilizado por defecto para firmar los xml de las evidencias y los documentos pdf generados por
el sistema.
Obligatorio
DEFAULT_CERTIFICATE_PASS
Contraseña del certificado utilizado por defecto para firmar los xml de las evidencias y los documentos pdf
generados por el sistema.
Obligatorio
TSA_URL
URL de acceso al servicio de sellos de tiempo TSA.
No obligatorio
TSA_USER
Clave de acceso al servicio de sellos de tiempo TSA.
No obligatorio
TSA_USER_PASSWORD
Clave de acceso al servicio de sellos de tiempo.
No obligatorio
Para versiones superiores a la 3.2.6 es reemplazado por la variable TSA_PASS
config.properties
19
TSA_ALIAS
Alias del certificado utilizado para acceso al servicio de sellos de tiempo TSA. Este certificado debe estar incluido
en el fichero cacert definido en la variable SIGNATURE_JKS_PATH
No obligatorio. Solo para entornos con TSA securizados mediante certificado.
TSA_PASS
Contraseña para el acceso al servicio de sellos de tiempo TSA. Dependiendo del tipo de conexión puede ser la
contraseña para accesos con usuario/contraseña o la contraseña del certificado para accesos mediante certificado.
No obligatorio
config.properties
20
Certificados
Viafirma documents hace uso de las claves privadas de los siguientes certificados.
Certificado de firma.
Certificado para la TSA (Opcional).
Además hace uso de las siguientes claves públicas
Clave pública del certificado del tercero de confianza para la encriptación de los datos biométricos de las firmas.
Claves públicas de las CA de los certificados de firma y de TSA.
¿Dónde se almacena cada uno de los certificados?
Viafirma documents tiene dos almacenes de certificados.
El primero de ellos, al que denominaremos SIGNATURE_JKS, incluye los certificados empleados en los procesos de
firma y encriptación:
Certificado de firma.
Certificado para la TSA.
Clave pública del certificado del tercero de confianza para la encriptación de los datos biométricos de las firmas.
La ubicación de este almacen viene definida enla variable SIGNATURE_JKS_PATH.
El segundo de ellos, al que denominaremos TRUSTED_JKS, incluye las claves públicas de las CA de los certificados
de firma y de TSA.
La ubicación de este almacen viene definida en la variable TRUSTED_JKS_PATH.
Configuración del SIGNATURE_JKS
Las variables de configuración asociadas al mismo son:
SIGNATURE_JKS_PATH: Ruta física del almacén de certificados empleados para la firma y encriptación.
SIGNATURE_JKS_PASSWORD: Contraseña del almacén de certificados empleados para la firma y encriptación.
DEFAULT_ENCRYPTION_KEY_ALIAS: Alias de la clave pública del certificado empleado para la encriptación de
los datos de las firmas biométricas.
DEFAULT_CERTIFICATE_ALIAS: Alias del certificado utilizado por defecto para firmar los xml de las evidencias y
los documentos pdf generados por el sistema.
DEFAULT_CERTIFICATE_PASS: Contraseña del certificado anterior.
TSA_ALIAS: Alias del certificado utilizado para acceso al servicio de sellos de tiempo TSA.
TSA_PASS: Contraseña del certificado anterior.
Certificadodefirma
21
Certificadodefirma
22
Generación de csr para enviárselo a una CA
Veamos los pasos a realizar para generar el csr para la creación del certificado.
1. Solicitar los datos del DNAME que necesitaremos para generar el csr. También sería conveniente pedir el alias del
certificado que se va a generar. La CA nos proporcionará los siguientes datos:
CN
SN
O
OU
E
ST
C
Validez
Longitud de clave
2. Generar la clave privada dentro de un jks con el keytool referenciando al Keystore.
Para ello se debe ejecutar la siguiente instrucción modificando los valores proporcionados.
keytool -genkeypair -alias alias_del_certificado -keyalg RSA -keysize
LONGITUD_DE_CLAVE_PROPORCIONADO -sigalg SHA256withRSA -keystore cacerts.jks -dname
"CN=CN_PROPORCIONADO, SERIALNUMBER=SN_PROPORCIONADO, O=O_PROPORCIONADO,
OU=OU_PROPORCIONADO, EMAIL=E_PROPORCIONADO, ST=ST_PROPORCIONADO,
C=C_PROPORCIONADO" -validity VALIDEZ_PROPORCIONADA
Tras ejecutar esta instrucción nos solicitará introducir la contraseña para el almacén de certificados primero y luego
para el propio certificado.
NOTA1:Encasodequealgunodeloscamposproporcionadosenelpunto1contengacomaseránecesario
escaparlareemplazandola,por\,
PorejemplosielCNesVIAFIRMA,S.A.deberaponerCN=VIAFIRMA\,S.A.
NOTA2:Sielcacertproporcionadoenlaintrucciónexisteseinstalaráelcertificadoenél.Ycuandosesolicite
Sinoexistesecreaunnuevocacert.
3 Exportar el CSR para enviar a la CA para que lo firmen. En nuestro ejemplo el crt será certificado.csr. Para ello
ejecutamos la siguiente instrucción:
keytool -certreq -alias alias_del_certificado -file certificado.csr -keystore cacerts.jks
4 Enviar el csr generado a la CA, la cual nos devolverá un crt. En nuestro ejemplo el crt será certificado.crt.
GenerarCSR
23
5 Debemos descargarnos los certificados padres del certificado crt. Posiblemente sean proporcionados por la CA, sino
será necesario descargarlos de Internet. Si los certificados padres (rootCA y/o subCA) no están en formato DER (.crt),
los convierto con la instrucción:
openssl x509 -in rootCA.pem -outform DER -out rootCA.crt
openssl x509 -in subCA.pem -outform DER -out subCA.crt
6 Concatenamos en un único certificado los dos o tres .crt (dependiendo si dispone de subCA o no). Para ello
ejecutamos la siguiente instrucción:
cat certificado.crt subCA.crt rootCA.crt > cert-with-chain.der
7 Importamos al jks el certificado cert-with-chain.der recién generado. El alias debe ser el mismo que asignamos en el
paso 2 (alias_del_certificado). De esta forma se reemplazará el certificado creado en el paso 2.
keytool -importcert -keystore cacerts.jks -alias alias_del_certificado -file cert-with-chain.der
Tras ejecutar esta instrucción nos solicitará introducir las contraseñas proporcionadas en el punto 2 para el almacén de
certificados primero y luego para el propio certificado. También nos solicitará si queremos confiar en las claves
públicas, a lo cual debemos contestar que si.
De esta forma tendremos en cacert.jks con el certificado que se empleará para la firma en servidor de las peticiones en
viafirma documents.
GenerarCSR
24
Primer acceso
Una vez completada la instalación de viafirma documents e instalada la licencia podremos acceder a la aplicación. Para
ello en el proceso de instalación se crea un usuario administrador por defecto cuyas credenciales de acceso son:
Usuario: admin
Contraseña: admin
Por motivos de seguridad se recomienda la modificación de la contraseña de este usuario tras el primer acceso.
El primer paso a realizar debe ser la configuración de la aplicación. La información al respecto puede encontrarla en el
apartado Configuración de los sistemas del manual de administador.
Primeracceso
25
Histórico de versiones
Backend
App iOS
App Android
Históricodecambiosyversiones
26
Histórico de versiónes del backend
Versión 3.3.5
Fecha: 09-noviembre-2016
Versión de la base de datos: 0.0.67
No incluye cambios de configuración
Cambios:
Se añade el generador de formularios a la edición de plantillas.
Versión 3.3.4
Fecha: 03-noviembre-2016
Cambios:
Modificación de la pantalla de listado de usuarios. Se eliminan las pestañas y se muestran todos los usuarios en el
mismo listado.
Mejoras en las búsquedas. No se pierden los criterios de búsqueda al realizar acciones sobre los registros.
Corregidos problemas con el timezone.
Corregido problema con la función wm_concat en las últimas versiones de Oracle.
Corregido problema con el encoding del json de callback.
Versión 3.3.3
Fecha: 30-septiembre-2016
Cambios:
Mejora del consumo de memoria de la aplicación.
Mejora de los mensajes de callback a url https.
Versión 3.3.2
Backend
27
Cambios:
Corrección de la internalización.
Versión 3.3.1
Cambios:
Corregida la expiración de mensajes cuando la fecha es porporcionada en un mensaje enviado mediante el
servicio REST.
Nueva funcionalidad de mensajes sin evidencias y con firma en servidor.
Correcciones menores.
Versión 3.3.0
Fecha: 19-agosto-2016
Cambios:
Soporte a la firma y envío de peticiones sin conexión a internet.
Mejora del envío de peticiones.
Mejora de la búsqueda de dispositivos.
Mejora en la generación de formularios desde plantillas.
Mejora en la activación y desactivación de usuarios.
Mejora de la administración de plantillas.
Versión 3.2.8
Cambios:
Backend
28
Mejorada la expiración de usuarios.
Mejorado el envío de notificaciones a dispositivos iOS.
Versión 3.2.7
Fecha: 11-julio-2016
Cambios:
Corregida la búsqueda de grupos.
Mejoras en las estadísticas.
Corregido el estado de las firmas en el detalle de firma de una petición. Salían siempre como no válidas aunque
fueran correctas.
Versión 3.2.6
Fecha: 4-julio-2016
Cambios:
Soporte a TSA con certificado.
Mejoras en la selección de usuario en Redactar.
Versión 3.2.5
Fecha: 21-junio-2016
Cambios:
Corrección de la geolocalización.
Inclusión del atributo hidden en los items del formulario.
Mejoras en la generación de formulario desde una plantilla.
Versión 3.2.4
Backend
29
Cambios:
Mejora en la eliminación de los ficheros temporales.
Añadido método al Servicio REST para buscar plantillas por código.
Versión 3.2.3
Fecha: 6-mayo-2016
Cambios:
Mejora en las firmas posicionadas en el pdf mediante doble tap.
Soluciona problemas al guardar la configuración.
Versión 3.2.2
Fecha: 3-mayo-2016
Cambios:
Mejoras en la validación de la licencia.
Versión 3.2.1
Fecha: 28-abril-2016
Cambios:
Modificado el periodo máximo de inactividad de un usuario a 365 días.
Mejora del método addCache del Servicio REST.
Mejoras en la redacción de peticiones.
Solucionado problema "demasiados ficheros abiertos".
Mejoras en el cierre de sesión.
Añadido Java Melody.
Añadida nueva configuración para indicar si se desean eliminar los pdf firmados al eliminar las peticiones.
Mejoras en las plantillas de tipo PDF.
Backend
30
Permitir a los administradores asociar plantillas y grupos a los usuarios en la edición de los mismos.
Versión 3.2.0
Cambios:
Mejoras en la redacción de peticiones.
Solucionado problema al editar aplicaciones.
Añadido contador de peticiones pendientes y borradores.
Solucionado problema al rechazar y crear copia.
Mejoras en el detalle de una petición. Añadida descarga del JSON de la petición en el detalle de la misma y
eliminado el botón descargar PDF para peticiones que no han sido aún firmadas.
Mejorado el envío de peticiones.
Añadido método al Servicio REST para registrar usuarios.
Corrección de bugs menores.
Mejorado el log de la aplicación.
Añadido el método addCache del Servicio REST.
Añadido el tipo de plantilla cache, para enviar documentos pdf que han sido anteriormente añadidos a la cache de
la aplicación con el método addCache.
Mejora de las notificaciones PUSH de iOS y Android.
Añadido método al Servicio REST para la creación de un PDF desde una plantilla.
Mejorada la seguridad del Servicio REST.
Mejoras en la geolocalización de las peticiones finalizadas.
Deprecados los métodos de la versión 1 del servicio REST.
Mejoras en el rechazo de peticiones.
Permitir el envío de mensajes desde el servicio REST sin politicas. En este caso se emplean las de la plantilla.
Añadido valor por defecto para el parámetro DEFAULT_CUSTODY_CODE. Ya no es obligatorio indicarlo en el
fichero de configuración o en el contexto.
Versión 3.1.3
Fecha: 9-marzo-2016
Incluye cambios de configuración
Cambios:
Mejoras en el envío de peticiones.
Mejoras en la pantalla de redacción.
Backend
31
Versión 3.1.2
Fecha: 4-marzo-2016
Cambios:
Solucionado problema en la comprobación del estado del sistema.
Añadida restricción de unicidad a los consumer key de las aplicaciones.
Añadido callback cuando los mensajes expiran.
Añadida la gestión de la api-keys al apartado de configuración de la aplicación.
Solucionado el envío de correos electrónicos con SSL.
Versión 3.1.1
Fecha: 25-febrero-2016
Cambios:
Eliminada las actualización automática de la pantalla de estadísiticas.
Solucionado problema con la autenticacón de usuarios cuyo código incluye una @.
Usuarios que no tienen rol solo pueden modificar su contraseña en el backend.
Mejoras en la validación de la licencia.
Solucionado problema con las notificaciones.
El código de usuario deja de ser case sensitive.
Añadida validación de DNI.
Añadido método al Servicio REST para rechazar peticiones por código.
Añadida funcionalidad para recordar la contraseña.
Añadida funcionalidad para dar de alta usuarios sin indicarles la contraseña y que estos reciban un correo con un
enlace para indicar su contraseña.
Campo email obligatorio en la importación de usuarios.
Mejoras menores en el servicio REST.
Eliminado el uso de itext.
Eliminados enlaces de descarga de los certificados de las aplicaciones si no han sido cargados previamente.
Añadido parámetro de configuración URL_PROTOCOL.
Resolución de problemas menores.
Versión 3.0.2
Fecha: 29-enero-2016
Backend
32
Cambios:
Eliminada integración con viafirma platform y viafirma manager.
Solucionado problema al realizar el autoregistro de un dispositivo.
Eliminadas las estadísticas
Permitir externalizar la configuración al fichero config.properties en lugar del contexto.
Permitir la creación de nuevas plantillas a usuarios con el rol USER.
Versión 2.X
Puede consultar el historial de cambios para versiónes 2.X en el siguiente enlace:
http://doc.viafirma.com/mobile-services/changelog.html
Backend
33
Cambios de configuración del backend
Versión 3.1.3 - directorio para ficheros de configuración
A partir de la v3.1.3 todos los ficheros de configuración pueden estar en un directorio específico y elegido por el cliente
durante la instalación.
Nos referimos a los siguientes ficheros de configuración:
config.properties
hazelcast.xml
logback.xml
ubicados en versiones anteriores en:
<tomcat_path>/webapps/documents/webapps/documents/WEB-INF/classes/
y que ahora podrán ubicarse en el directorio definido en la variable DOCUMENTS_HOME. Esta variable se define en el
contexto de la aplicación entregada por defecto en el war, pudiéndose consultar y modificar en:
<tomcat_path>/conf/Catalina/localhost/documents.xml
Ejemplo:
<Environmentdescription="Documentshome"name="DOCUMENTS_HOME"
override="false"type="java.lang.String"value="/home/vdocuments/config"/>
Cambiosdeconfiguración
34
Histórico de versiones de la aplicación iOS
Versión 3.3.0
Cambios:
Nueva validación (dni_nie) con soporte para DNI y NIE.
Correcciones menores
Versión 3.2.3
Cambios:
Versión 3.2.2
Fecha: 3-mayo-2016
Cambios:
Corrección de la inserción de las firmas haciendo doble tap.
Versión 3.2.1
Cambios:
Corrección del proceso de actualización automático.
Versión 3.2.0
AppiOS
35
Cambios:
Captura de firmas y evidencias sin conexión.
Añadido soporte a Touch ID
Nuevo diseño de la cámara.
Envío de logs desde el dispositivo.
Añadido soporte a lápices Wacom.
Añadida imagen previa del pdf.
Versión 3.1.3
Fecha: 30-marzo-2016
Cambios:
Mejoras en la validación del formulario.
Mejoras en la autenticación sin conexión.
Versión 3.1.1
Cambios:
Añadida imagen de la firma en png.
Corrección de errores.
Versión 3.1.0
Cambios:
Opciones disponibles sobre las peticiones finalizadas configurables.
Añadida validación del DNI.
Versión 2.X
Puede consultar el historial de cambios para versiones 2.X en el siguiente enlace:
AppiOS
36
AppiOS
37
Histórico de versiones de la aplicación Android
Versión 3.3.0
Cambios:
Nueva validación (dni_nie) con soporte para DNI y NIE.
Versión 3.2.0
Cambios:
Mejoras de las funcionalidades sin conexión.
Mejoras en el diseño.
Añadida pantalla de ajustes.
Rechazar mensajes deslizandolos hacia la izquierda en el listado.
Envío de logs desde el dispositivo.
Versión 3.1.0
Fecha: 8-marzo-2016
Cambios:
Versión 3.0.0
Fecha: 1-marzo-2016
Cambios:
Captura de firmas y evidencias sin conexión.
AppAndroid
38
Versión 2.X
Puede consultar el historial de cambios para versiones 2.X en el siguiente enlace:
AppAndroid
39
Glosario
ddd
ddd
Glosario
40

Versión 3.2.0

Transcripción

Documentos relacionados

Please help us by providing the following documents. We must have