Los jugadores son:

1. Jbpm 3.2 como motor de workflow.
2. Formula 2 como motor de formularios.
3. Viafirma 1.3.5 como motor de firma digital.

La aplicación que los implementa está desarrollada con Seam + JSF + JPA.

La Descripción

Básicamente el requisito era el siguiente: un formulario completado por un usuario entraba en un flujo de transiciones en el que distintos departamentos y/o personas tenían que ir aprobándolo con su firma digital.

La solución tradicional con la que contábamos se basaba en recuperar los datos del primer formulario, y en la transición adecuada los mostrábamos para que el firmante pudiera comprobar los datos (tareas).

Esto implicaba un esfuerzo en la redendirización nuevamente de los datos facilitados por el usuario, por lo que decidimos aprovechar las características de los componentes usados para simplicarlo todo.

Solución

Formula2 permite la identificación de los campos creados en el formulario. De esta manera nuestra solución consisitirá en identificar un mismo nombre de campo dentro de un mismo ProcessId.

Una vez asegurado en nuestro proceso esta identificación de campos, ahora toca el turno de Formula2; duplicaremos el formulario original, y modificaremos todos sus campos al tipo ReadOnly, de manera que el firmante no pueda modificar los datos mostrados en el formulario inicial.

Opcionalmente, a esta copia del formulario se le podrán añadir campos adicionales, como por ejemplo, un campo de observaciones o bien otros campos para informar valores necesarios en la siguiente transición.

Esta tarea de modificar cada campo de un formulario podría resultar algo engorrosa, pero solo habrá que hacerlo una vez, ya que la primera copia con todos sus campos “ReadOnly” nos serviría  de base para las sucesivas copias que necesitemos, y para estas copias ya no será necesario modificar la propiedad de sus campos.

Resultado

A medida que el diseño del flujo (process-definition) va ejecutando las tareas e invocando los distintos formularios, los actores propietarios de dichas tareas van firmando con su certificado digital los formularios.

El proceso de firma es delegado a nuestro al motor de firma VIAFIRMA. Cuando éste completa la transacción de firma, devuelve todos los datos necesarios a nuestro sistema. En este caso, Jbpm interpreta estos datos de firma como variables del proceso, añadiéndolos como un dato más de la transición.

Como valor agregado, estos datos de firma y los contenidos en el formulario son indexados mediante Lucene (implementando openSearch), y de esta forma ofrecemos al usuario la posibilidad de buscar su proceso por el código de firma que se le informó.

Tras el proceso de firma, se le muestra al usuario una pantalla de recibo, donde se le accede a toda la información del proceso con las distintas opciones:

• Descarga del formulario que fue firmado.
• Descarga del comprobante de firma, con los datos del firmante y de la transacción (fecha, hora y certificado usado).
• Id. de las tarea y proceso.
• Link permanente a su proceso.
• Todo ello apoyado con imágenes bidimensionales como el Qr-Code con el resumen de la firma y el BarCode con el código de la firma.

Posibles Conflictos

Seguro que a alguno ya se le ha pasado por la cabeza un posible conflicto:

¿Qué ocurre si para un mismo ProcessId se ven involucrados 2 formularios que no son copias el uno del otro, pero el identificador que le pusimos al campo es el mismo, por ejemplo ID_PROFESOR?

• si el segundo formulario NO es una copia del primero, pero tiene un campo con el mismo Id., efectivamente nuestro proceso hará que este segundo formulario se renderice con el valor introducido para ese campo en el primer formulario. Pero, al no tratarse de una copia, el campo no será del tipo ReadOnly (o no debiera), por lo que el valor podría ser modificado por el usuario.
• La solución a este tipo de conflictos en nuestro caso: anteponer un identificador del formulario a modo de prefijo en el identificador del campo. Por ejemplo: FRM_9_ID_PROFESOR.

Resumen

Gracias a la funcionalidad de Formula2 para identificar los campos y duplicar formularios conseguiremos una sencilla implementación de un ESCRITORIO DE FIRMA.

• Nos ahorramos construir N formularios.
• Nos ahorramos la lógica para recuperar y renderizar los datos asociados al formulario original y que necesitamos ir mostrando a cada firmante.

Aúpa Viafirma!! :-D

El próximo Lunes 20 de Octubre, nos vamos a Málaga a presentar Viafirma en la Conferencia Internacional de Sofrware Libre( programa ).

Este caso es el que nos pasó recientemente, y lo peor de todo es que era en un entorno de producción.

El ejemplo en cuestión se trataba de un sistema que hacía uso de VIAFIRMA (nuestra plataforma de autenticación y firma digital). Cuando ésta enviaba los correos firmados digitalmente con el certificado instalado en producción, el “maravilloso” Exchange empezó a aplicar una regla para los correos cuyo destinatario fuese un correo externo.

Esta regla no era otra que interceptar el correo e inyectarle un disclaimer en el pie, del tipo “…este mensaje contiene información confidencial….”.

El catastrófico resultado en los correos que recibían los usuarios:


La firma no es válida
El mensaje incluye una firma digital, pero la firma no es válida.
La firma no coincide correctamente con el contenido del mensaje. El mensaje parece que ha sido manipulado después de que el remitente lo firmara. Usted no debería confiar en la validez de este mensaje hasta que verifique su contenido con el remitente.
Firmado por: “la empresa en cuestión”


Para hacer más difícil aún la detección del problema, y sin saber aún por qué, Exchange no siempre estaba aplicando esta regla y se escapaban correos sin el disclaimer.

Por tanto, en sistemas de información donde apuesten por la automatización del formato de los correos salientes desde el lado servidor siempre tendrán que tener en cuenta qué REGLAS de INTEGRIDAD podrían estar rompiendo.

 ¿Por qué una versión comercial de Viafirma?

En la mayoría de los casos, nuestros clientes desean utilizar Viafirma sobre aplicaciones que no son compatibles con GPL; además, nos exigen soporte técnico, mantenimiento, plazos para nuevos desarrollos, tiempos de respuesta, una documentación completa, y en resumen, unas garantías que no ofrece la versión GPL. Por este motivo y para poder financiar los nuevos desarrollos a los que nos estamos enfrentando, hemos creado el portal  viafirma.com.

¿Implica esto un cambio de filosofía de la versión Software Libre?

No. Tenemos tanto que agradecer a la comunidad que nuestra intención sigue siendo apostar por una plataforma libre . De hecho acabamos de liberar como GPL la nueva versión de Viafirma 1.3.2, si lo desean pueden consultar la lista completa de nuevas funcionalidades en viafirma.org.

Sobre la firma electrónica 

No confundamos firma electrónica con autenticación con certificado. Podemos acceder (login) a una aplicación web con nuestro certificado, y que sea accesible. En lo que se refiere a la firma electrónica en una aplicación web, hay sin embargo una serie de conceptos claros. El proceso técnico es más o menos como el que sigue (ahorrando varios pasos para no hacer un post tipo Biblia):

1. El usuario introduce los datos que debe firmar. Esto puede ser de muchas formas; rellenar un formulario HTML, adjuntar un fichero, etc.
2. El navegador del usuario debe generar un resumen (digest) con un algoritmo hash (tipo MD5 o SHA-1) de la información a firmar.
3. El navegador debe utilizar la clave privada del certificado digital del cliente para encriptar esta información. Esta encriptación es simétrica; lo que se encripta con la clave privada podrá ser desencriptada con la clave pública, y sólo con esta. Para realizar esta operación, el navegador debe consultar de alguna forma el almacén de certificados del cliente, hacerle escoger el certificado con el que quiere firmar, y utilizar la clave privada almacenada en el certificado escogido para encriptar ese hash. Ya tenemos la firma: es el hash encriptado.
4. El navegador envía al servidor de firma todos los datos necesarios: el hash encriptado y la clave pública del certificado digital del cliente. Ahora éste lo almacena con el formato que se considere más oportuno. En cualquier momento se puede verificar la validez de esa firma con una sencilla operación: desencriptando la firma con la clave pública del certificado, y comparándola con el resultado de realizar el hash Almacenar el documento original con su firma (el hash encriptado). De esta forma, si algún día se quiere comprobar que lo que introdujo el usuario (el documento original) no ha sido modificado maliciosamente (lo que le confiere validez legal), se puede realizar una sencilla operación de comprobación de firma, consistente en desencriptar la firma con la clave pública del certificado digital, obteniendo el hash, y aplicando el algoritmo de hash sobre el documento original. Si ambos hash coinciden, la firma es válida.

El problema es que los pasos 2 y 3 deben realizarse en cliente, es decir, en el navegador. Esto se totalmente necesario y obligatorio; precisamente, uno de los puntos clave para mantener la seguridad del proceso se basa en que la clave privada del certificado del cliente nunca sale de la máquina del cliente. Hay un número finito de tecnologías para ejecutar esto en un navegador web: lo más normal son applets Java (como el conocido OpenOCES, que utilizamos en Viafirma y que usan otras plataformas como la de Safelayer) o clientes Active X, invocados desde Javascript. De hecho, éste es uno de los puntos claves para que un trámite telemático sea lo más universal y usable posible: la calidad del componente cliente. Por ejemplo, la semana pasada tardé dos horas, experimentos en 3 máquinas diferentes (ya varios navegadores en cada una, aunque con Opera o Safari no llegas muy lejos) y un buen número de reinstalaciones de componentes para conseguir cambiar a mi mujer de médico de cabecera, debido a la infame calidad de los applets Java de firma de la plataforma @Firma. Si a mí me costó tanto, no quiero imaginar qué le ocurrirá a un usuario de a pie. El mayor problema es que funciona muy mal con el JRE Java 6, pero debería tenerse en cuenta que, salvo que se configure de forma diferente, el JRE se autoactualiza automáticamente, con lo que a estas alturas hasta el panadero de la esquina tiene instalado Java 6 en su máquina.

Sobre la accesibilidad web 

En lo que se refiere a la accesibilidad web, las pautas WAI te exigen que para acceder a tu contenido web no sea imprescindible el uso de applets o javascript. En concreto, la pauta 6.3 dice que “Asegúrese de que las páginas sigan siendo utilizables cuando se desconecten o no se soporten los scripts, applets u otros objetos programados. Si esto no es posible, proporcione información equivalente en una página alternativa accesible”.

Según esta pauta entendemos que no podemos tener una calificación AA de accesibilidad si utilizamos javascript y applets, ya que deberíamos tener una página alternativa. El problema es que no podemos tener una página alternativa ya que la operación que realizamos no se puede realizar de otra forma de forma legal.

Sobre las Administraciones Públicas 

Por último, las Administraciones Públicas exigen por regla general que sus portales web, incluyendo sus oficinas virtuales, alcancen un nivel AA de accesibilidad, esto es, cumplan todos los puntos de verificación de prioridad 1 y 2.

Pero también exigen que para que una operación telemática sea legal, se haga utilizando firma electrónica que, como hemos visto, tiene problemas insalvables de accesibilidad porque hoy por hoy no es posible firmar sin ejecutar lógica de cliente que no todos los navegadores o dispositivos de usuario tienen por qué soportar. Por ello, la alternativa legal que podemos dar a nuestra web con firma electrónica es que el usuario se vaya a la institución físicamente.

¿No es un contrasentido? Se piden dos cosas incompatibles entre sí.

Una conclusión: quedarse en medio.

Bajo mi punto de vista, no debemos olvidar que las pautas WAI se refieren al acceso al contenido. Una Oficina Virtual está mucho más cerca de una aplicación web que de un portal, por lo que debe plantearse si las pautas aplican con la misma restrictividad. En todo caso, siempre se puede tratar de que toda la web sea accesible realmente, y sacar la zona dotada de firma electrónica de la declaración de accesibilidad. Y esperar a que la tecnología avance para superar estos escollos.

Esto desde luego no es ninguna sorpresa. Siguiendo un modelo tal vez inspirado en Tractis, Telefónica aprovecha su innegable renombre para erigirse en tercero de confianza en transmisiones electrónicas seguras. Supongo que habrán optado por un modelo de negocio de abstraer la lógica a las empresas (hay que tener en cuenta el fuerte posicionamiento de Telefónica en el mercado de PYMEs), proveyéndoles de soluciones sencillas que solucionen problemas complejos como estos.

Sin embargo, lo que me sorprende sobremanera es lo siguiente; vuelvo a citar al diario “El País”: “La operadora lleva trabajando más de un año en el proyecto, con una inversión de más de 400 millones de euros…”.

¿400 millones de euros? Repaso un poco proyectos por orden de coste decreciente, la importante cantidad que costó CERES, lo que le ha costado a la Junta de Andalucía la creación de @Firma, lo que nos ha costado hacer Viafirma (tener a un crack como Félix ayuda, claro)… pero, ¿400 millones de euros?

Divagando un poco, supongo que habrán comprado 100 o 200 servidores Windows, 300 Linux y 400 Sun (hay probar Solaris, Aix o HP UX, para ver si van bien), y estarán comparando. Supongo que hay dos o tres nuevos turistas espaciales. También supongo que estarán programando en ensamblador, que siempre es más seguro, y a ser posible de espaldas y a la luz de las velas en noches de luna llena. Los algoritmos de encriptación existentes no les valdrán, estarán creando los suyos propios basándose en la lectura de las vías tomistas. No estarán programando con las manos, que cada cual se imagine otra parte del cuerpo con la que se pueda realizar pulsaciones de teclado (bueno, tal vez estén programando a boli e intentando escanearlo con un OCR).

Corcho, pero todavía me sobran euros para darme la vuelta al mundo :-)

En todo caso, divagando, he llegado a la conclusión. Telefónica, para el siguiente presupuesto, nosotros te lo hacemos por la mitad de lo que te digan ;-)

• Migración del stack WebSerice utilizado, antes Xfire, ahora JAX-WS 2.1.
• Nuevo método para el envío de emails firmados digitalmente.
• Cache de CRLs para minimizar el número de accesos a CRLs externas.
• Soporte de firma en servidor (indicando el alias y el password) y custodia de documentos firmados offline.
• Actualizada la versión de la librería OpenId para el soporte completo de OpenId 1.1 y OpenId 2.0 (draft)
• Mejorada la documentación de instalación y creada aplicación pre-empaquetada .war .
• Añadido digito de control al identificador de firma.
• Validación y recuperación de documentos custodiados mediante el identificador del documento.
• Uso de friend-url para el acceso a documentos custodiados, ej:http://viafirma.viavansi.com/viafirma/v/Y1MW-9LE3-JE81-2087-8160-3774.
• Mejorado el renderizado del QR-CODE, añadida información hash del documento y mejoradas en el formato de la etiqueta.
• Mejorado el renderizado del justificante pdf, para formatos no A4.
• Parametro para control de acceso al Servicio Web , ALLOWED=”ip,ip2″ indica que ips tienen permiso para acceder al servicio web.
• Soporte de certificados almacenados en “Acceso a Llaves” de Mac OSX (Con esto ya tenemos soporte completo de Mac OS X).
• Solución de bugs en el css para IE6 e IE7.
• Solución de bug en el envio de mimetype al navegador.
• Añadido método al api cliente, que permite retornar una imagen png con el código de barras y QR code del documento custodiado.
• Se ha añadido a la demo de la plataforma la posibilidad de firmar un documento de ejemplo, sin necesidad de subir uno ya existente.
• Mejorado el parseador de Oids, para extraer correctamente los datos del certificado.

Para aquellos lectores que no lo sepan, Viafirma es uno de nuestros productos ASVPDM (Aplicaciones Software de Viavansi Para Dominar el Mundo). Es una VA (Validation Authority) Open Source; una VA permite abstraer las operaciones de autenticación y firma digital con certificados digitales. Tras la última release, se convierte en la primera plataforma 100% software libre que permite la validación del DNI electrónico.

Viafirma es un servicio externo que se encarga de estas operaciones, y da un API a terceras aplicaciones que necesitan autenticación o firma digital. Es decir, podemos disponer de una sola instancia de Viafirma en una red, y varias aplicaciones cliente.

Durante el proceso de desarrollo de la última release hemos hecho diferentes pruebas de soporte. En este post voy a tratar de explicar el sencillo proceso para utilizar el DNI electrónico (DNIe) sobre Windows. En mi caso he usado Windows XP, aunque en principio Vista está perfectamente soportado.

Los pasos a seguir son los siguientes:

1. Tener un DNI electrónico :-D Esto es sencillo, lo hacen sobre la marcha en varias comisarías de Policía de España. Además, no hace falta que tengas caducado el anterior. La tasa es de 6,70€. Me fijé que tardó muchísimo en la escritura de los certificados (unos 10 minutos). Con el DNIe te dan un sobre con un PIN que protege la tarjeta. Lo mejor es cambiarlo inmediatamente. En la Comisaría donde lo saqué (Oviedo) tenían un par de kioskos interactivos donde se podía cambiar de forma sencilla.
2. Instalar los drivers de algún lector de tarjetas criptográficas. En mi caso instalé 2 que tenía antiguos para la lectura de tarjetas donde había alojado mi certificado de la FNMT-RCM; en concreto, un lector de C3PO (el típico del CryptoKit) y un lector de Bit4id. Aprovecho para recomendar encarecidamente este proveedor, son gente realmente seria y rápida.
3. Instalar librerías del DNI electrónico. En la web del proyecto se puede descargar un fichero ZIP instalable que contiene el CSP (”Cryptographic Service Provider”). En Linux, Unix o MAC usaríamos un PKCS#11.
4. Listo para probar!!! Tras reiniciar (mérito de nuestro MS Windows) enchufamos el lector al USB e insertamos el DNI electrónico. Probamos con la demo de Viafirma tanto la autenticación como la firma. La demo es una sencillísima aplicación cliente de Viafirma que simplemente solicita el certificado para autenticar, lo valida y muestra su contenido (también permite una firma de fichero). Para acceder a la lectura, la librería CSP del DNIe nos pide de vez en cuando el PIN de la tarjeta que ya habíamos modificado en la Comisaría de Policía. Escogemos el certificado adecuado, y voilá! Todo funcionando perfectamente

A este respecto cabe destacar algunos aspectos:

• El DNI electrónico incorpora 2 certificados, uno destinado a autenticación y otro destinado a Firma.
• Para la validación del DNIe se ha implementado la validación mediante OCSP. No existe la posibilidad de validar directamente el estado del certificado contra una CRL.
• El acceso a la tarjeta es tremendamente lento (minutos). No sé si será cosa de Windows, o porque ninguno de los 2 lectores que probé están optimizados para el DNIe, pero el hecho de que tardase 10 minutos en generar los certificados durante la emisión me hace sospechar que es que es así. Sinceramente, si se confirma, me parece un freno terrible para la universalización del DNI electrónico.

Seguiremos posteando los pasos para utilizar el DNI electrónico en otros sistemas operativos (Linux y Mac).

Con esta funcionalidad, Viafirma se convierte en la primera plataforma software libre con soporte para el eDNI.

Si lo desea puede probar su dni electrónico en la aplicación de demostración.

Gracias a Viafirma 1.2 ahora es mucho mas fácil que otras aplicaciones hagan uso del eDNI para autenticar a sus usuarios o solicitarles que autoricen o firmen documentos y transacciones.

Principales cambios en la versión 1.2:

• Soporte para la validación de certificados utilizando OCSP (Online Certificate Status Protocol RFC 2560)
• Soporte para la autenticación utilizando el DNI electrónico.
• Soporte para la firma de documentos utilizando el DNI electrónico.
• API cliente WebSercice, con lo que ahora tenemos disponibles tres APIs: RMI, WebService y OpenId.
• Admite la configuración offline, desactivando la validación de certificados revocados.

Una vez alcanzadas las funcionalidades básicas, y con la experiencia adquirida en las instalaciones y adaptaciones que hemos realizado de la plataforma, en la próxima versión nos centraremos en mejorar la documentación pública, crear una guía con los errores mas comunes encontrados y mejoras en los ejemplos de integración.