Table of Contents. Página 2

Transcripción

1

2 Table of Contents 1. Introduction 2. Instalación i. Instalación en Tomcat ii. Instalación en weblogic iii. Configuración de la aplicación i. Lista de parámetros disponibles iv. Configuración de cache Hazelcast.xml v. Configuración de logs logback.xml vi. Configuración de fuentes para plantillas 3. Acceso al API Rest con OAuth 1.0 i. Uso de la capa de servicios Rest ii. Uso de servicios desde cliente Java 4. Uso de políticas de firma y evidencias en mensajes 5. Uso de formularios 6. Uso de plantillas i. Convertir plantillas docx a pdf mediante Acrobat ii. Convertir plantillas docx a pdf mediante LibreOffice 7. Procedimiento de actualización i. Novedades de la versión ii. Actualización a la versión iii. Actualización a la versión iv. Actualización a la versión v. Actualización a la versión vi. Histórico de cambios y versiones vii. ANEXO: actualización 2.0 a 2.5 Página 2

3 Documentación de Mobile Services La solución Viafirma Documents forma parte de un ecosistema compuesto por otros componentes no descritos en este manual y que son necesarios para su funcionamiento. Como parte de la suite de Viafirma, los componentes necesarios son: Viafirma Platform Viafirma Manager Viafirma Mobile Services Viafirma Document ios y Android En este manual sólo se describe el procedimiento de instalación y configuración de Mobile Services. El resto de componentes tiene su propia documentación que deberá ser consultada en cada caso. Introduction Página 3

4 Versión actualizado el 03/06/2015 Introduction Página 4

5 Instalación Necesita disponer de: Un servidor de aplicaciones JEE (Tomcat 7.X o Weblogic ) Una base de datos Oracle 10 o Postgres 9 Acceso a una instalación de Viafirma Platform Acceso a una instalación de Viafirma Manager Un certificado digital para la firma de documentos Una clave pública para el cifrado de datos biométricos de la firma del usuario Disponer de las aplicaciones móviles para ios o Android para hacer uso de la solución desde dispositivos móviles. Instalación Página 5

6 Instalación en Tomcat 7.X A continuación se explicarán las configuraciones recomendadas para el servidor de aplicaciones Apache Tomcat y conseguir así un rendimiento óptimo. El contexto debe editarse en la siguiente ubicación: / /conf/server.xml /conf/catalina/localhost/mobile-services.xml Configuración en Clúster Mobile Services permite su configuración en clúster para alta disponibilidad. En cada nodo que se desee disponer habrá que configurar el tomcat con las propiedades adecuadas en cada caso. Tomcat configurado para clúster: server.xml (/conf/server.xml) Peso de Ficheros Admitidos Configurar tamaño máximo de ficheros recibidos Por defecto Tomcat limita el envío mediante POST de 2Mb. Para ampliar este tamaño habrá que indicarlo de forma específica tal y como se muestra en el siguiente ejemplo que se permite hasta 10Mb.: Esta configuración habrá que indicarla en el server.xml del Tomcat ( /conf/server.xml ), y en caso de disponer de un clúster, habrá que repetir la configuración en cada nodo. Instalación en Tomcat Página 6

7 Instalación en Weblogic Instalación en weblogic Página 7

8 Configuración en fichero config.properties Configuración de la aplicación Página 8

9 Lista de parámetros disponibles APPLICATION_URL Disponible desde: 1.0 URL de acceso público a la plataforma por ejemplo: PERSISTENCE_STORAGE Disponible desde: 1.0 Ruta física de disco en la que se persistirán los datos almacenados en cache, documentos temporal y mensajes recibidos por la plataforma y que están actualmente en ejecución. AUDITORY_PATH Disponible desde: 1.0 Ruta física de disco donde se guardan los xml que que contienen los mensajes procesados por la plataforma a modo de auditoría. VIAFIRMA_URL Disponible desde: 1.0 URL de acceso al servidor de Viafirma Platform VIAFIRMA_USER Disponible desde: 1.0 Usuario de acceso a los servicios de Viafirma Platform VIAFIRMA_PASS Lista de parámetros disponibles Página 9

10 Disponible desde: 1.0 Clave de acceso a los servicios de Viafirma Platform REPOSITORIO_IMPL Disponible desde: 1.0 Implementaciones disponibles para la persistencia de datos o documentos, plantillas, documentos firmados, datos de aplicaciones, etc. Actualmente están disponibles las siguientes implementaciones: filesystem --> org.hanuman.framework.external.repository.managerfilerepositorysimpleim pl ftp --> org.hanuman.framework.external.repository.ftpfilerepositorysimpleimpl computec --> org.hanuman.framework.external.repository.computecfilerepositoryimpl:co mputec1 filesystem.template.path_base Disponible desde: 1.0 Deprecated desde: Ruta física en disco donde se persistirán las plantillas configuradas en el sistema. filesystem.template.versionar Disponible desde: 1.0 Deprecated desde: filesystem.application.path_base Disponible desde: 1.0 Deprecated desde: Ruta física en disco donde se persistirán los datos de las aplicaciones configuradas en el sistema. filesystem.application.versionar Lista de parámetros disponibles Página 10

11 Disponible desde: 1.0 Deprecated desde: 'selected_impl'.signed.path_base Disponible desde: 1.0 Ruta donde se persistirá una copia de los documentos firmados en el sistema. Se puede reemplazar 'selected_impl' por los valores [filesystem ftp] 'selected_impl'.signed.versionar Disponible desde: 1.0 Este parámetro solo puede tener el valor false AUTHENTICATOR_CHAIN Disponible desde: 2.0 Implementación utilizada para el control de acceso de usuarios a la plataforma, por ejemplo: com.viafirma.mobile.services.security.databaseauthenticator para gestionar en acceso mediante base de datos. SEUS_URL Disponible desde: 2.0 URL de acceso al servicios de autenticación de usuarios Seus, este parámetro solo es necesario en el caso de que se quiera utilizar: AUTHENTICATOR_CHAIN=com.viafirma.mobile.services.security.SeusAuthenticator VIAFIRMA_MANAGER_WS_URL Disponible desde: 2.0 URL de acceso al servidor de Viafirma Manager VIAFIRMA_MANAGER_WS_USER Lista de parámetros disponibles Página 11

12 Disponible desde: 2.0 Usuario de acceso a los servicios de Viafirma Manager VIAFIRMA_MANAGER_WS_PASS Disponible desde: 2.0 Clave de acceso a los servicios de Viafirma Manager VIAFIRMA_CUSTODY_STORAGE Disponible desde: 2.0 Ruta de persistencia de documentos firmados que se utilizará para las nuevas aplicaciones creadas en Viafirma Manager directamente desde Mobile Services al crear un nuevo usuario MAIL_HOST_NAME Disponible desde: URL de acceso al servidor de envío de s MAIL_SMTP_USER Disponible desde: Usuario de acceso al servidor de envío de s configurado MAIL_SMTP_PASS Disponible desde: Clave del usuario de acceso al servidor de envío de s configurado MAIL_FROM Disponible desde: Lista de parámetros disponibles Página 12

13 Dirección de correo electrónico desde la que aparecerá como remitente de los s enviados MAIL_CALLBACK_SUBJECT Disponible desde: Asunto de los s enviado a las direcciones de informadas en el parámetro callbackmails de un mensaje MAIL_CALLBACK_ATTACHMENT_XML Disponible desde: Puede tener valores [true false] en caso de valer true, se adjuntara el mensaje, en formato xml, resultante de la operación como adjunto al enviado a las direcciones informadas en el parámetro callbackmails de un mensaje MAIL_CALLBACK_ATTACHMENT_PDF Disponible desde: Puede tener valores [true false] en caso de valer true, se adjuntara el documento resultante de la operación como adjunto al enviado a las direcciones informadas en el parámetro callbackmails de un mensaje MAIL_CALLBACK_PRINT_FORM_PARAMS Disponible desde: Puede tener valores [true false] en caso de valer true, se adjuntara al contenido del , los valores del formulario utilizado para la generación del documento, si el parámetro callbackmailsformkeys del mensaje está informado solo se enviarán las los valores de los campos de formulario de las claves definidas en este parámetro, si el parámetro callbackmailsformkeys no está informado, se mandarán todos los valores del formulario MAIL_CALLBACK_PRINT_DISCLAIMER Disponible desde: Lista de parámetros disponibles Página 13

14 Texto del disclaimer que se añadirá al contenido de los enviados por el sistema, como resultado de la ejecución de la tarea de callback computec1.external_signed.temporal_storage Disponible desde: Directorio físico de persistencia temporal de los documentos que serán transferidos al sistema externo computec computec1.external_signed.computec_service Disponible desde: URL de acceso al servicio de computec computec1.external_signed.service_path Disponible desde: Path del servicio en el que se recibirán los documentos enviados computec1.external_signed.async_transfer Disponible desde: Puede tener valores ["true" "false"] indica si la transferecia se realiza de forma síncrona o asíncrona computec1.external_signed.transfer_async_period Disponible desde: Indica cada cuantos segundos se ejecuta el proceso periódico de tranferencia de documentos computec1.external_signed.max_retry_count Disponible desde: Lista de parámetros disponibles Página 14

15 Número máximo reintentos de transferecia de documentos en caso de error OAUTH_REQUEST_MAX_AGE Disponible desde: 2.0 Número máximo de milisegundos de diferencia permitidos entre que se solicita una petición al servidor y es recibida por el servidor. Si este parámetro no está informado o tiene el valor 0 no se realiza la comprobación CREATE_TEMPLATE_EXAMPLES Disponible desde: Puede tener valores [true false] en caso de valer true se instalan/actualizan de forma automática al iniciar el servidor las plantillas de ejemplo creadas para demostrar la funcionalidad del sistema SYSTEM_STATUS_ERROR_SUBJECT Disponible desde: Asunto del correo enviado en caso de detectar algún error en el proceso automatizado de control de estado del sistema. SYSTEM_STATUS_ERROR_RECIPIENTS Disponible desde: Lista de cuentas de correos a la que se mandaran los errores derivados del proceso automatizado de control de estado del sistema. SYSTEM_STATUS_ERROR_THREAD_TIMER_DELAY Disponible desde: Delay del hilo que ejecuta la automatización anterior. SYSTEM_STATUS_ERROR_THREAD_TIMER_PERIOD Lista de parámetros disponibles Página 15

16 Disponible desde: Period del hilo que ejecuta la automatización anterior. REPORT_TRANSFER_JOB_SUBJECT Disponible desde: Asunto del correo que es enviado con el adjunto del informe diario de transferencias de mensajes. Debe contener el literal [reportdate] que cambiará en tiempo de ejecución a la fecha del informe. REPORT_TRANSFER_JOB_RECIPIENTS Disponible desde: Lista de cuentas de correo a la que se mandará el informe anterior. REPORT_TRANSFER_JOB_BODY Disponible desde: Cuerpo del correo explicado anteriormente. Debe contener el literal [reportdate] que cambiará en tiempo de ejecución a la fecha del informe. METADATA_CIPHER_PUBLIC_KEY Disponible desde: Valor de la clave pública que se utilizará para el cifrado de metadatos de aquellas evidencias que no tengan informado el parámetro metadatacipherpublickey. En caso de que este parámetro no sea configurado solo se cifrarán los metadatos de las evidencias que tengan informado el atributo metadatacipherpublickey en el mensaje que solicita la petición Lista de parámetros disponibles Página 16

17 Configuración de cache Hazelcast.xml Configuración de cache Hazelcast.xml Página 17

18 Configuración de logs logback.xml Configuración de logs logback.xml Página 18

19 Instalación de fuentes para plantillas Para poder generar el PDF a partir de una plantilla con las fuentes originales usadas en la plantilla es necesario que dichas fuentes estén instaladas en el servidor. A continuación se muestra un ejemplo de instalación de fuentes (fonts) desde línea de comandos: viafirma@server01a1:/usr/share/fonts/truetype$ ls CRONMI_.TTF CRONOSMM.TTF CronosPro-BoldSubh.otf ONYX.TTF ttf-dejavu viafirma@server01a1:/usr/share/fonts/truetype$ sudo chmod 777 *.TTF viafirma@server01a1:/usr/share/fonts/truetype$ sudo chmod 777 *.otf viafirma@server01a1:/usr/share/fonts/truetype$ ls CRONMI_.TTF CRONOSMM.TTF CronosPro-BoldSubh.otf ONYX.TTF ttf-dejavu viafirma@server01a1:/usr/share/fonts/truetype$ fc-cache -fv /usr/share/fonts: caching, new cache contents: 0 fonts, 1 dirs /usr/share/fonts/truetype: caching, new cache contents: 4 fonts, 1 dirs /usr/share/fonts/truetype/ttf-dejavu: caching, new cache contents: 6 fonts, 0 dirs /usr/x11r6/lib/x11/fonts: skipping, no such directory /usr/local/share/fonts: caching, new cache contents: 0 fonts, 0 dirs /home/viafirma/.fonts: skipping, no such directory /var/cache/fontconfig: not cleaning unwritable cache directory /home/viafirma/.fontconfig: cleaning cache directory fc-cache: succeeded viafirma@server01a1:/usr/share/fonts/truetype$ Configuración de fuentes para plantillas Página 19

20 Acceso al API Rest con OAuth 1.0 Documentación oficial de OAuth 1.0 Se pueden configurar la seguridad de acceso al API de cada aplicación configurada en Mobile Services de dos formas: OAuth 1.0 a nivel de aplicación Solo es necesario conocer las credenciales de acceso de la aplicación y en las peticiones solo se registra la información de la aplicación solicitante. Se deben de informar los parámetros 'Consumer Key' y 'Consumer Secret' de OAuth, como resultado en la cabecera de la petición http se debe de informar de lo siguiente, en el parámetro Authorization en el Header de la petición. OAuth realm=" oauth_consumer_key="com.viafirma.mobile.services.crm", oauth_signature_method="hmac-sha1", oauth_timestamp=" ", oauth_nonce="kubrja", oauth_version="1.0", oauth_signature="zvpxpedplikqrni0tmq3gpzmzl0%3d" En las siguientes capturas podemos ver un ejemplo de acceso al API Rest con el cliente Postman Acceso al API Rest con OAuth 1.0 Página 20

21 OAuth 1.0 a nivel de usuario Solo es necesario conocer las credenciales de acceso de la aplicación y los datos de acceso de un usuario válido en el sistema, en las peticiones solo se registra la información de la aplicación solicitante y del usuari solicitante. Se deben de informar los parámetros 'Consumer Key', 'Consumer Secret', 'Token' y 'Token Secret' de OAuth, como resultado en la cabecera de la petición http se debe de informar de lo siguiente, en el parámetro Authorization en el Header de la petición. OAuth realm=" oauth_consumer_key="com.viafirma.mobile.services.demo", oauth_token="48a0bad01f064a69a19d310c5d71c3b6", oauth_signature_method="hmac-sha1", oauth_timestamp=" ", oauth_nonce="dn876b", oauth_version="1.0", oauth_signature="8pi9lg7qvuyo0ioepcv%2bmx5qqjm%3d" En las siguientes capturas podemos ver un ejemplo de acceso al API Rest con el cliente Postman En primer lugar necesitamos perdir un token de acceso haciendo uso de las credenciales de acceso de nuestra aplicación Acceso al API Rest con OAuth 1.0 Página 21

22 Una vez tenemos un token de acceso tenemos que aceptar este token haciendo uso de este token temporal y de los datos de acceso de un usuario válido en el sistema Acceso al API Rest con OAuth 1.0 Página 22

23 Una vez aceptado el token podremos utilizar el API Rest con este token durante un periodo de tiempo configurado en el sistema pasado el cual se informará de que el token ha caducado y que debemos de solicitar uno nuevo para poder seguir utilizando el API. Acceso al API Rest con OAuth 1.0 Página 23

24 Ejemplo de token caducado Acceso al API Rest con OAuth 1.0 Página 24

25 Uso de la capa de servicios Rest Ejemplo de uso de servicios rest haciendo uso de postman Envio desde el CRM un mensaje que solo genere el documento pdf En la pestaña de OAuth de postman tenemos que indicar los valores correctos en los campos 'Consumer Key' y 'Consumer Secret' tal cual podemos ver en la siguiente captura Realizar una petición POST Enviando el siguiente json IMPORTANTE el código del workflow tiene que ser EX005 Uso de la capa de servicios Rest Página 25

26 { } "version" : "00001", "workflow" : { "code" : "EX005", "history" : [ ] }, "notification" : { "text" : "Generar pdf", "detail" : "Ejemplo que solo genera un pdf y ejecuta el callback según lo tenga configurado" }, "document" : { "templatecode" : "022_example", "templatetype" : "docx", "items" : [ { "key" : "KEY_01", "type" : "text", "label" : "KEY_01", "required" : true, "disabled" : false }, { "key" : "KEY_02", "type" : "text", "label" : "KEY_02", "required" : false, "disabled" : false }, { "key" : "KEY_03", "type" : "text", "label" : "KEY_03", "required" : false, "disabled" : false }, { "key" : "KEY_04", "type" : "text", "label" : "KEY_04", "required" : false, "disabled" : false } ] } Ejemplo de recuperación de documento generado realizando petición GET a 40 Uso de la capa de servicios Rest Página 26

27 Uso de la capa de servicios Rest Página 27

28 Mobile Services SDK Java Cliente Java para Mobile Services - Viafirma Histórico de cambios y versiones Integración en proyecto maven Es necesario añadir el siguiente repositorio <repository> <id>viavansi-repo</id> <name>viavansi Maven Repository</name> <url> </repository> Añadir la siguiente dependencia <dependency> <groupid>com.viafirma</groupid> <artifactid>ms-sdk-java</artifactid> <version>2.x.x</version> </dependency> Ejemplo de uso: Recuperar información de un mensaje conocido el código Ejemplo de Autenticación OAuth a nivel de usuario V1Api api = new V1Api(); // URL de acceso al API REST api.setbasepath(urlapi); // OAuth consumer key api.setconsumerkey(consumerkey); // OAuth consumer secret Uso de servicios desde cliente Java Página 28

29 api.setconsumersecret(consumersecret); // Solicitar un nuevo token Token token = V1oauthApi.getInstance().requestToken(); api.settoken(token.getoauth_token()); api.settokensecret(token.getoauth_token_secret()); // Aceptar el token recibido token = V1oauthApi.getInstance().accessToken(userCode, userpass, "client_auth"); api.settoken(token.getoauth_token()); api.settokensecret(token.getoauth_token_secret()); // Ejemplo de como recuperar un message conocido su código Message message = V1messagesApi.getInstance().getMessageByCode(" R255"); Ejemplo de envio de mensaje para solo generar documentos pdf Ejemplo de autenticación OAuth a nivel de aplicación V1Api api = new V1Api(); // URL de acceso al API REST api.setbasepath(urlapi); // OAuth consumer key api.setconsumerkey(consumerkey); // OAuth consumer secret api.setconsumersecret(consumersecret); //Create message Message message = new Message(); //Create workflow Workflow workflow = new Workflow(); workflow.setcode("ex005"); message.setworkflow(workflow); //Create notification info Notification notification = new Notification(); notification.settext("notification Demo"); notification.setdetail("generate a example document from template"); message.setnotification(notification); //Create a template document Document document = new Document(); document.settemplatecode("022_example"); document.settemplatetype("docx"); Uso de servicios desde cliente Java Página 29

30 //Add dato to template List<Item> items = new ArrayList<Item>(); Item item = new Item(); item.setkey("key_01"); item.setlabel("test key 1"); item.setvalue(uuid.randomuuid().tostring()); items.add(item); item = new Item(); item.setkey("key_02"); item.setlabel("test key 2"); item.setvalue(uuid.randomuuid().tostring()); items.add(item); item = new Item(); item.setkey("key_03"); item.setlabel("test key 3"); item.setvalue(uuid.randomuuid().tostring()); items.add(item); item = new Item(); item.setkey("key_04"); item.setlabel("test key 4"); item.setvalue(uuid.randomuuid().tostring()); items.add(item); document.setitems(items); message.setdocument(document); //Send message String messagecode = V1messagesApi.getInstance().sendMessage(message); Uso de servicios desde cliente Java Página 30

31 Uso de políticas de firma y evidencias Estructura de los documentos firmados Firma del documento PDF El PDF será firmado electrónicamente, con un certificado digital, y dependiendo de la política de firma indicada en el JSON se realizará en un formato de firma que incluya un sello de tiempo (hora oficial). Dependiendo de las evidencias capturadas durante el proceso de firma, el PDF mostrará tantas anotaciones como evidencias se hayan capturado, referenciando en cada caso al XML asociado, el cual estará disponible como anexo al propio PDF, por tanto, podremos encontrarnos con PDFs que tengan más de un XML asociado. Además, al PDF se le insertará como anexo el XML que se describe en el siguiente punto. Firma de los XML adjuntos al PDF El XML contendrá datos relativos a la operación de firma digitalizada o cualquier evidencia capturada durante el proceso. Parte de la información recogida en este XML irá en claro y otra parte irá cifrada. Esta última se cifrará en función de la política de cifrado indicada en el JSON. Además, el XML estará firmado electrónicamente, con un certificado digital, y dependiendo de la política de firma indicada en el JSON se realizará en un formato de firma que incluya un sello de tiempo (hora oficial). Entre los datos que se recogen en el XML también encontraremos datos asociados de forma biunívoca al PDF que el usuario firmó. Uso de políticas de firma y evidencias en mensajes Página 31

32 Parámetros de configuración de una firma digitalizada Ayuda contextual Para incluir un texto de ayuda en el lienzo de firma que se muestra en el dispositivo móvil, usaremos el parámetro digitalizedsignhelptext. { } "key": "digitalizedsignhelptext", "value": "Firma de ejemplo" Posición de la firma digitalizada En la política podemos determinar si la firma capturada se puede insertar libremente en el documento, haciendo doble tap sobre el documento, o bien insertarla en una posición conocida. Para ello, se usarán los siguientes parámetros: signpositionenable: lo usaremos para permitir la posición manual de la firma. Los valores permitidos son true y false. En caso de indicar false en el parámetro signpositionenable, necesitamos los siguientes parámetros: { } "key": "signpositionenable", "value": "false" digitalizedsignrectangle: lo usaremos para definir dónde insertar la firma, en el formato: Y, X, width, height { } "key": "digitalizedsignrectangle", "value": "{\"y\":\"240\",\"x\":\"270\",\"width\":\"160\",\"height\":\"65\"}" page: para indicar el número de la página donde se insertará la firma. Para insertarlo en la última se indica -1. Uso de políticas de firma y evidencias en mensajes Página 32

33 { } "key": "page", "value": "1" Tipos de cifrado Usaremos el parámetro op para indicar qué tipo de operación de cifrado se va a realizar. Los valores permitidos son dos: pen = el cifrado se realiza en servidor biometric = el cifrado se realiza en el propio dispositivo móvil { } "key": "op", "value": "pen" Clave pública de un certificado informado Usaremos la siguiente combinación: op = pen biometricalias y biometricpass existe están informados: Como resultado tendremos un XML cifrado en servidor con la clave pública del certificado indicado, el cual previamente fue instalado en el servidor. Ejemplo: { "key": "op", "value": "pen" }, { "key": "biometricalias", "value": "viafirmadocuments" }, { "key": "biometricpass", "value": "12345" }, { "key": "DIGITALIZED_SIGNATURE_FORMAT", "value": "XADES_EPES_ENVELOPED" Uso de políticas de firma y evidencias en mensajes Página 33

34 } En el ejemplo anterior además hemos informado el parámetro DIGITALIZED_SIGNATURE_FORMAT para que el XML también sea firmado con el certificado informado, y que también debió ser instalado en el servidor previamente. Clave pública informada en el propio JSON Usaremos la siguiente combinación: op = biometric biometriccryptopem nota: si nos informan una clave pública en el JSON, usaremos preferentemente el tipo de operación cifrado en local (dispositivo móvil). Como resultado tendremos un XML cifrado en el dispositivo móvil, con la clave pública informada en el parámetro biometriccryptopem. Ejemplo: { "key": "op", "value": "biometric" }, { "key": "biometriccryptopem", "value": "MIIFbDCCBFSgAwIBAgIIGtUapa" }, { "key": "biometricalias", "value": "viafirmadocuments" }, { "key": "biometricpass", "value": "12345" }, { "key": "DIGITALIZED_SIGNATURE_FORMAT", "value": "XADES_EPES_ENVELOPED" } En el ejemplo anterior además hemos informado los parámetros biometricalias, biometricpass y DIGITALIZED_SIGNATURE_FORMAT para que el XML también sea Uso de políticas de firma y evidencias en mensajes Página 34

35 firmado con el certificado informado, y que también debió ser instalado en el servidor previamente. Configuración de la firma del PDF La key DIGITALIZED_SIGN_PDF_SIGNATURE_FORMAT nos indicará el formato de firma a utilizar, por ejemplo: { } "key": "DIGITALIZED_SIGN_PDF_SIGNATURE_FORMAT", "value": "PDF_PKCS7_T" Formatos permitidos para la firma del PDF PADES_BASIC (no incluye de tiempo) PADES_BES (sello de tiempo opcional) PADES_EPES (necesita sello de tiempo) PDF_PKCS7 (NO incluye sello de tiempo) PDF_PKCS7_T (necesita sello de tiempo) nota: para incorporar un sello de tiempo es necesario tener configurada una TSA, bien en viafirma platform o bien en las credenciales utilizadas en viafirma manager. Certificado para la firma del PDF El certificado que se usará para la firma del PDF se define en las keys alias y pass: { "key": "alias", "value": "viafirmadocuments" }, { "key": "pass", "value": "12345" } Este par de keys son obligatorias y su uso está ligado a la key DIGITALIZED_SIGN_PDF_SIGNATURE_FORMAT. Uso de políticas de firma y evidencias en mensajes Página 35

36 Configuración de firma del XML La key DIGITALIZED_SIGNATURE_FORMAT nos indicará el formato de firma del XML que se incluye dentro del PDF y que contiene los datos biométricos y otras evidencias capturadas durante el proceso de firma, por ejemplo: { } "key": "DIGITALIZED_SIGNATURE_FORMAT", "value": "XADES_EPES_ENVELOPED" Formatos permitidos para la firma del XML XADES_EPES_ENVELOPED (sello de tiempo opcional) XADES_T_ENVELOPED (necesita sello de tiempo) XADES_XL_ENVELOPED (necesita sello de tiempo) XADES_A_ENVELOPED (necesita sello de tiempo) XMLDSIG (NO incluye sello de tiempo) XMLSIG_ENVELOPING (NO incluye sello de tiempo) nota: para incorporar un sello de tiempo es necesario tener configurada una TSA, bien en viafirma platform o bien en las credenciales utilizadas en viafirma manager. Certificado para la firma del XML El certificado que se usará para la firma del XML se define en las keys biometricalias y biometricpass: { "key": "biometricalias", "value": "viafirmadocuments" }, { "key": "biometricpass", "value": "12345" } Este par de claves son obligatorias y su uso está ligado a la key DIGITALIZED_SIGNATURE_FORMAT. Uso de políticas de firma y evidencias en mensajes Página 36

37 Parámetros de configuración de las evidencias de una firma digitalizada Además de la firma digitalizada (descrita en el capítulo 2), el proceso permite capturar otras evidencias electrónicas, y además en un orden determinado. En este capítulo vamos a explicar una política de evidencias basadas en la captura de huellas dactilares (fingerprint) y en la captura de imágenes desde la cámara del dispositivo móvil. Es importante aclarar que el tratamiento de una firma digitalizada (haciendo uso por ejemplo de stylus bluetooth), NO se incluye dentro de la política de evidencias, quedando éstas reservadas únicamente para las capturas de fotos y huellas. Política con Evidencias Se permiten una o varias evidencias por cada política, es decir, una política de configuración podrá llevar asociada un array de eviencias, y cada evidencia tendrá su propia configuración. Es importante destacar, que al igual que se hace con la firma digitalizada, las evidencias pueden llevar asociada una política de firma para que los datos queden cifrados y/o firmados electrónicamente (con certificado digital). Ejemplo de política con 2 evidencias: { "policies": [ { "evidences": [ { "evidences_1_config" }, { "signature_evidence_1_policy" } ] }, { "evidences": [ { "evidences_2_config" }, { "signature_evidence_2_policy" Uso de políticas de firma y evidencias en mensajes Página 37

38 } ] } } ] Evidencia del tipo Imagen Usaremos el parámetro type para indicar el tipo de evidencia imagen. "type": "ANNOTATION" Los parámetros que podemos usar en esta evidencia para su configuración son los siguientes: { } "type": "ANNOTATION", "helptext": "Foto del cliente", "typeformatsign": "XADES_EPES_ENVELOPED", "certificatealias": "viafirmadocuments", "certificatepassword": "12345", "positions": [ { "page": 1, "rectangle": { "width": 100, "height": 145, "x": 417, "y": 330 } } ] Key Descripción type Tipo de evidencia, y debemos indicar FINGER_PRINT helptext Ayuda contextual que aparecerá en modo alert en la pantalla del dispositivo móvil antes de iniciar la captura. typeformatsign Formato en el que se firmará el XML que contendrá la evidencia capturada. Los valores posibles se describen en el capítulo Firma del XML. certificatealias Alias del certificado que se usará para la firma; este certificado Uso de políticas de firma y evidencias en mensajes Página 38

39 debe estar instalado previamente en servidor y asociado a las credenciales gestionadas por viafirma manager. certificatepassword Password del certificado que se usará para la firma; este certificado debe estar instalado previamente en servidor y asociado a las credenciales gestionadas por viafirma manager. positions Array de posiciones, pudiendo indicar una o varias posiciones en la que deseamos representar la imagen capturada. Para cada posición, indicaremos el número de la página, la posción dentro de la página y el tamaño. positions: page Número de la página en la que se va a insertar la imagen capturada. positions: rectangle Usaremos las coordenadas X,Y para determinar el vértice superior izquierdo del rectángulo imaginario para representar la imagen, e indicaremos ancho (width) y alto (height) del mismo. Evidencia del tipo huella Usaremos el parámetro type para indicar el tipo de evidencia huella, y el parámetro devicetype para indicar el vendor del dispositivo que vamos a utilizar para la captura. Al indicar un vendor relacionado con la captura de huellas, el dispositivo móvil cederá el control al accesorio para inciar la captura. "type": "FINGER_PRINT", "devicetype": "vendorid" Por ejemplo, para conectar con un lector de huella de Tactivo, Precise Biometric, usaremos el siguiente identificador: "devicetype": "ifmid" Los parámetros que podemos usar en esta evidencia para su configuración son los siguientes: { "type": "FINGER_PRINT", "helptext": "Huella del cliente", "devicetype": "ifmid", "typeformatsign": "XADES_EPES_ENVELOPED", "certificatealias": "viafirmadocuments", "certificatepassword": "12345", "metadatacipherpublickey": "MIIFbDCCBFSgAwIBAgIIGtUapa...", "positions": [ { "page": 1, Uso de políticas de firma y evidencias en mensajes Página 39

40 } ` ] } "rectangle": { "width": 100, "height": 145, "x": 417, "y": 330 } Key Descripción type Tipo de evidencia, y debemos indicar FINGER_PRINT helptext Ayuda contextual que aparecerá en modo alert en la pantalla del dispositivo móvil antes de iniciar la captura. devicetype ID del vendor que usaremos para la captura. Por ejemplo, para Tactivo, usaremos ifmid typeformatsign Formato en el que se firmará el XML que contendrá la evidencia capturada. Los valores posibles se describen en el capítulo Firma del XML. certificatealias Alias del certificado que se usará para la firma; este certificado debe estar instalado previamente en servidor y asociado a las credenciales gestionadas por viafirma manager. certificatepassword Password del certificado que se usará para la firma; este certificado debe estar instalado previamente en servidor y asociado a las credenciales gestionadas por viafirma manager. metadatacipherpublickey clave pública con la que será cifrado el contenido del atributo metadata de la evidencia utilizando un cifrado RSA/None/NoPadding en UTF-8 al cual se le aplicará un base64. positions Array de posiciones, pudiendo indicar una o varias posiciones en la que deseamos representar la huella capturada. Para cada posición, indicaremos el número de la página, la posción dentro de la página y el tamaño. positions: page Número de la página en la que se va a insertar la representación de la huella capturada. positions: rectangle Usaremos las coordenadas X,Y para determinar el vértice superior izquierdo del rectángulo imaginario para representar la huella, e indicaremos ancho (width) y alto (height) del mismo. Uso de políticas de firma y evidencias en mensajes Página 40

41 Uso de formularios El sistema permite crear formularios para ser usados como entrada de datos desde el propio dispositivo móvil. Su funcionamiento se describen en los siguientes pasos: Crear una plantilla a partir de un.odt o.docx Generar formulario para la plantilla seleccionada. Esta generación construirá un JSON con tantos elementos como variables hayan sido detectadas en la plantilla. También se podrán crear nuevos formularios de forma directa haciendo uso del diseñador de formularios. Cuando un formulario es informado (rellenado) desde el dispositivo móvil, automáticamente se solicitará al servidor (mobile services) un nuevo mensaje que dará lugar al envio de una notificación, la cual nos llegará inmediatamente al mismo dispositivo desde el que se completó el formulario. Una vez recibida dicha notificación, el PDF ya se mostrará ajustado a la plantilla que fue vinculada al FORM, y con los datos informados por el usuario desde el propio dispositivo móvil. Tipos de Datos En los formularios que mostraremos en el dispositivo móvil se podrán usar los siguientes tipos de datos: Caja de texto que valida si el texto introducido es un con formato correcto. Uso: { "key": " ", "type": "text", "label": " ", "placeholder": "insert ", "size": "33", Uso de formularios Página 41

42 "validation": " " } Como se muestra en la imagen, el teclado muestra para facilitar la introducción del correo. Teléfono Caja de texto que habilita el teclado númerico para facilitar al usuario la introducción del número. Uso: { "key": "number", Uso de formularios Página 42

43 } "type": "tel", "label": "Teléfono", "placeholder": "insert phone", "size": "33" Como se muestra en la imagen, se habilita el teclado de teléfono. Fecha Muestra calendario para que el usuario seleccione la fecha. Uso: { "key": "date", Uso de formularios Página 43

44 } "type": "date", "label": "Date", "placeholder": "date", "size": "33" El usuario no podrá introducir tipo de dato incorrecto, sólo podrá seleccionar una fecha desde el objeto calendario mostrado. Fecha y Hora Muestra calendario, hora y minutos para que el usuario la seleccione. Uso: Uso de formularios Página 44

45 { } "key": "datetime", "type": "datetime", "label": "Datetime", "placeholder": "date time", "size": "33" El usuario no podrá introducir tipo de dato incorrecto, sólo podrá seleccionar una fecha y hora desde el objeto calendario mostrado. Hora Muestra hora y minutos para que el usuario los seleccione. Uso de formularios Página 45

46 Uso: { } "key": "time", "type": "time", "label": "Time", "placeholder": "time", "size": "33" El usuario no podrá introducir tipo de dato incorrecto, sólo podrá seleccionar una hora y minuto desde el objeto time mostrado. Fecha Actual Uso de formularios Página 46

47 Carga la fecha actual del dispositivo, y no permite su edición. Uso: { } "key": "today", "type": "todaytext", "format": "%w - %d %n %y", "monthnames": ["January", "February", "March", "April", "May", "June", "July", "August", "Sept "daynames": ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"] Formato por defecto: "%d/%m/%y" Posibles Valores: d: Day m: Month number n: Month name w: Day name y: Full year H: Hours M: Minutes S: Seconds i: ISO date Número Caja de texto que habilita el teclado númerico para facilitar al usuario la introducción del número. Uso: { } "key": "number", "type": "number", "label": "Number", "placeholder": "insert number", "size": "33" Uso de formularios Página 47

48 Este tipo de datos habilitará el teclado numérico del dispositivo móvil. Textarea Área de texto. Uso: { } "key": "textarea", "type": "textarea", "label": "Textarea", "size": "100", "height": "120", "placeholder" : "This is a textarea" Uso de formularios Página 48

49 height: se mide en píxeles, y por defecto es de 100. Select Muestra el conjunto de valores contenidos en la lista informada dentro del JSON. Uso: { "key": "select1", "type": "select", "label": "Select Sample", "list" : "combos" } Lista precargada para el Select La lista que alimentará al select del ejemplo 1 deberá definirse al principio del JSON tal y como se muestra en el siguiente ejemplo: "lists" : { "combos" : ["Value 1", "Value 2", "Value 3"] } Checkbox Muestra el conjunto de valores contenidos en la lista informada dentro del JSON. Uso: { } "key": "checkbox1", "type": "checkbox", "label": "Checkboxes", "list" : "checkboxes" Devolvemos string de lista de los valores seleccionados separados por ' ' Lista precargada para el Checbox Uso de formularios Página 49

50 La lista que alimentará al checkbox anterior deberá definirse al principio del JSON tal y como se muestra en el siguiente ejemplo: "lists" : { "checkboxes" : ["Value 1", "Value 2", "Value 3"] } Radio Muestra el conjunto de valores contenidos en la lista informada dentro del JSON. Uso: { "key": "radios1", "type": "radio", "label": "Radios", "list" : "radios" } Lista precargada para el Radio La lista que alimentará la lista de valores del radio del ejemplo anterior deberá definirse al principio del JSON tal y como se muestra en el siguiente ejemplo: "lists" : { "radios" : ["Value 1", "Value 2", "Value 3"] } Cómo definir varias listas precargadas? Para alimentar varias listas que serán usadas en distintos elementos del formularios, y siguiendo los ejemplos anteriores, se podrán informar de la siguiente forma: "lists" : { "combos" : ["Value 1", "Value 2", "Value 3"], "checkboxes" : ["Value 1", "Value 2", "Value 3"], "radios" : ["Value 1", "Value 2", "Value 3"] } Uso de formularios Página 50

51 Listas Vinculadas Los selects pueden estar vinculados de forma que los valores mostrados en cada uno dependan de los seleccionados en un select anterior, como la típica selección de provincia y con ella se recarga el select de municipios que pertenecen a esa provincia. Para su uso nos ayudaremos del siguiente ejemplo: En 1er lugar definimos la lista padre: "lists" : { "listapaises" : ["España", "Colombia"] } En segundo lugar definimos la listas hijas: "nestedlists" : { "listacomunidades" : { "España" : ["Andalucía", "Galicia", "Aragón"], "Colombia" : ["Atlántico", "Antioquia", "Cundinamarca"] } } Y por último definimos los combos (select): "items" : [ { "key": "combopaises", "type": "select", "label": "Países", "update": "comunidades", "list" : "listapaises" }, { "key": "combocomunidades", "type": "select", "label": "Comunidades", "nestedlist" : "listacomunidades" }] Observar que en el segundo combo no es necesario el atributo update porque este combo no actualiza a ningún otro combo hijo. Observar también que este segundo Uso de formularios Página 51

52 combo se usa el atributo nestedlist en lugar de list, como sí se usa en su combo padre. Item de Sólo Lectura Todos los items permiten el atributo "disabled" para que el valor introducido sólo sea de lectura y no permita su edición. { } "key": "name", "type": "text", "label": "Name", "placeholder": "insert name", "size": "33", "disabled": true Repetir valor de campo Para los items del tipo "text" se permiten el atributo "match" para indicar en la validación del formulario que el valor aquí indicado debe ser igual que el introducido en el item referenciados, tal y como se muestra en el siguiente Ejemplo: { "key": " ", "type": "text", "label": " ", "placeholder": "insert ", "required": true, }, { "key": " repeat", "type": "text", "label": "Repeat ", "placeholder": "repeat ", "required": true, "match": } ##### Tipo Link Este tipo de elemento se podrá usar para incluir enlaces html para llevar al usuario a contenido { "key": "help", "type": "link", "text": "help", "href": " } Uso de formularios Página 52

53 #### Validación de Datos Los tipos de datos descritos en el punto anterior podrán ser validados de la siguiente forma: Validación: requerido Todos los tipos de datos podrán incorporar la validación required. Ejemplo: { "key": "name", "type": "text", "label": "Name", "placeholder": "insert name", "size": "33", "required": true } ##### Validación: Supone una validación de un formato "conocido", y usamos una expresión regular para controlar qu { "key": " ", "type": "text", "label": " ", "placeholder": "insert ", "size": "33", "validation": " " } Observar que el tipo de dato es text, pero la validación del tipo llamará a una expresión ##### Validación con Expresión Regular Para cualquier otro tipo de dato que se desee validar se podrá usar, de forma explícita, una exp Para incluir una expresión regular como validación en cualquier componente que queramos montar e { "key": "age", "type": "text", "label": "Age", "placeholder": "insert age", "size": "33", "validationregex": "[0-9]+" } En el código anterior montamos un tipo texto para solicitar la Edad del Usuario, y en la validac ##### Validación Longitud de Campos Se podrá valida la longitud máxima y mínima de los campos de formularios del tipo text. Para ell Para incluir una expresión regular como validación en cualquier componente que queramos montar e Uso de formularios Página 53

54 { "key": "age", "type": "text", "label": "Age", "placeholder": "insert age", "size": "33", "validationregex": "[0-9]+" } ```` En el código anterior montamos un tipo texto para solicitar la Edad del Usuario, y en la validación usamos una expresión regular para que sólo admita valores del 0 al 9. Uso de formularios Página 54

55 Uso de plantillas para la generación de documentos pdf El sistema de plantillas immplementado en mobile services soporta formato Word (.docx) y formato openoffice (.odt), y está basado en la inclusión de variables de forma cómoda e intuitiva, tal y como se describe a continuación: Uso del prefijo "$" Para insertar en nuestro documento una variable sólo será neceario insertar en el lugar deseado el nombre de la variable precedida de "$", por ejemplo $client_surname. Nombre de cliente: $client_name Apellidos del cliente: $client_surname Importe de la compra: $purchase_amount Uso de plantillas Página 55

56 Uso merge field Otro mecanismo de insertar variables en nuestra plantilla será haciendo uso del merge field. Y a diferencia del mecanismo anterior, para insertar una nueva variable debemos posicionarnos en el lugar deseado y seleccionar la opción insertar campo del tipo Merg Field, que en cualquier caso dependeraá de la versión del Editor de Texto con el que se trabaje. Esta ilustración muestra explica el acceso a la opción merge field sobre una versión de Microsoft Word 2007 para Mac. Uso de plantillas Página 56

57 Convertir plantilla.docx a PDF rellenable mediante Acrobat Estos son los pasos para convertir una plantilla docx en un formulario rellenable pdf, utilizando Acrobat. Partiendo de una plantilla docx similar a la siguiente: 1. Seleccionamos la opción de edición de formularios desde el panel de Herramientas - > Formularios -> Editar : Convertir plantillas docx a pdf mediante Acrobat Página 57

58 2. Para crear los campos del formulario, seleccionaremos la opción Agregar nuevo campo -> Campo de texto : Convertir plantillas docx a pdf mediante Acrobat Página 58

59 3. Crearemos una caja de texto por cada campo: 4. Para asociar la caja de texto a un campo de formulario, pulsaremos el botón derecho del ratón para abrir el menú de edición, y seleccionaremos la opción Propiedades. En la pestaña General de este menú debemos editar obligatoriamente el campo Nombre, y deberá ser la key del campo: Convertir plantillas docx a pdf mediante Acrobat Página 59

60 5. Además, podremos configurar la fuente en la pestaña Aspecto de dicho menú: Una vez creados todos los campos, tendremos un documento similar al siguiente: Convertir plantillas docx a pdf mediante Acrobat Página 60

61 6. Para concluir la edición, pulsaremos el botón Cerrar edición de formulario, arriba a la derecha. 7. Y finalmente, guardaremos el documento y quedará disponible para subirlo como plantilla PDF en la aplicación mobile-services. Convertir plantillas docx a pdf mediante Acrobat Página 61

62 Convertir plantilla.docx a PDF rellenable mediante LibreOffice Estos son los pasos para convertir una plantilla docx en un formulario rellenable pdf, utilizando LibreOffice. Partiendo de una plantilla docx similar a la siguiente: 1. Abrimos el panel de control de formularios en el menú View Toolbars Form Controls Convertir plantillas docx a pdf mediante LibreOffice Página 62

63 2. En la segunda columna, tercera fila del panel vemos la herramienta para crear cajas de texto, y crearemos una por cada campo: Convertir plantillas docx a pdf mediante LibreOffice Página 63

64 3. Para asociar la caja de texto a un campo de formulario, pulsaremos el botón derecho del ratón para abrir el menú de edición, y seleccionaremos la opción Control : Convertir plantillas docx a pdf mediante LibreOffice Página 64

65 Veremos este panel de opciones para configurar la caja de texto: Convertir plantillas docx a pdf mediante LibreOffice Página 65

66 4. Debemos editar obligatoriamente la opción Name que deberá ser la key del campo: 5. Además, podremos configurar algunos aspectos de la caja de texto, como la posición exacta en el formulario, anchura, altura, color de fondo, borde, etc. Convertir plantillas docx a pdf mediante LibreOffice Página 66

67 6. Para configurar el tipo de fuente, entraremos en las opciones correspondientes donde podremos editarla: Así como modificar el color de la fuente: Convertir plantillas docx a pdf mediante LibreOffice Página 67

68 7. Una vez creados todos los campos, tendremos que exportar el documento a formato PDF. Para ello, buscamos la opción en el menú File Export as PDF Convertir plantillas docx a pdf mediante LibreOffice Página 68

69 Veremos este panel de opciones para exportar el documento: Convertir plantillas docx a pdf mediante LibreOffice Página 69

70 Debemos asegurarnos de marcar 'Create PDF form' en formato FDF, y permitiendo nombres de campos duplicados. 8. Seleccionamos la ruta donde queremos crear el documento PDF y ya estará disponible para subirlo como plantilla PDF en la aplicación mobile-services. Convertir plantillas docx a pdf mediante LibreOffice Página 70

71 Manual de actualización el sistema En las siguientes secciones se explicará con detalle, las acciones necesarias para que pueda actualizar una instalación de mobile-services a la última versión disponible. Debe de ejecutar los procedimientos de actualización de forma secuencial hasta llegar a la versión que desea instalar Procedimiento de actualización Página 71

72 Novedades en la v2.3 de viafirma documents Mejoras en backend Migración objetos temporales Se migrarán los objetos correspondientes a "messages" y "ficheros temporales" (PDF + imágenes). Se crea nueva tabla VD_TEMPORAL_DATA, donde los registros se borran cuando el message llega a uno de estos estados: responsed error expired Migración de recursos a base de datos Novedades de la versión Página 72

73 Se migrarán a base de datos las plantillas y los recursos necesarios para las apps móviles, como los.p12 necesarios para las push. Se ofrece además una nueva pantalla para iniciar los procesos automáticos de migración. Se usará la tabla ya existente VD_MESSAGE para persistir el mensaje durante todo el ciclo de vida. Se hará sobre el atributo "data" y en format JSON, permitiendo su indexación para búsquedas. Novedades de la versión Página 73

74 Se mantiene la gestión de borrado de esta tabla que ya se ofrecía en versiones anteriores. Migración de roles a grupos roles actuales = grupos La definición actual de roles será usada en un proceso automático de migración mediante el cual se creará un nuevo grupo para cada rol encontrado en la base de datos. Ejemplo: a partir del rol "Asesor A" se creará un grupo "Asesor A". todos los usuarios actuales con rol "Asesor A", pertenecerán al grupo "Asesor A". todas las plantillas asociadas a dichos usuarios, serán asociadas al grupo "Asesor A". Roles Tras la migración a grupos, los roles actuales serán eliminados, quedando reducidos a un conjunto de roles asociados a niveles de permisos sobre acciones a realizar en el backend. Novedades de la versión Página 74

75 Grupos Los grupos serán una asociación lógica de usuarios y permisos sobre el uso de plantillas. Los usuarios podrán usar sus propias plantillas + las asignadas al grupo o grupos a los que pertenezca. Importación de usuarios a partir de Excel Se ofrece nueva pantalla para iniciar la importación de usuarios, en la cual se ofrece una explicación de su uso así como la descarga de una plantilla en formato excel. El proceso de migración ofrece un resumen tras su finalización, detallando en cada caso qué registros fallaron. Novedades de la versión Página 75

76 Mejora del informe automático de transferencias Nueva excel remitida por correo electrónico con gráficas de históricos y estados. Novedades de la versión Página 76

77 Nueva gestión de grupos Un usuario podrá pertenecer desde cero a N grupos. Los grupos tendrán permisos de acceso a las plantillas. Un usuario podrá ver todas las plantillas autorizadas para su grupo y las suyas propias. Novedades de la versión Página 77