Aunque pueda parecer sorprendente, una de las principales novedades de la próxima versión 2.2 de Viafirma, que va a ser liberada en pocos días, es su integración con la plataforma @Firma v5.
Para el lector que no conozca @Firma (también conocido como aFirma), se trata de una plataforma de similares características funcionales a Viafirma, teniendo como principales responsabilidades el facilitar a terceras aplicaciones (que se integran con @Firma a través de una API cliente) el soporte de autenticación y firma digital con certificados digitales. Su desarrollo fue dirigido por la Junta de Andalucía, donde es la plataforma corporativa de autenticación y firma digital, y también así ha sido escogida por el MAP (Ministerio de Administraciones Públicas) como su herramienta base para este tipo de funcionalidades, cediendo su uso a cualquier de Administración Pública española. Hablamos por ello sin ninguna duda de una plataforma con una gran relevancia en el mercado y un más que importante número de implantaciones.
¿Por qué comentamos que «puede parecer sorprendente» esta nueva funcionalidad de Viafirma? Pues porque, como el lector habrá advertido, en principio Viafirma y @Firma «se dedican a lo mismo», es decir, a facilitar a aplicaciones el soporte de autenticación y firma electrónica. Entonces, ¿para qué integrar ambas plataformas?
La idea de su integración surge de la posibilidad de aislar responsabilidades dentro del proceso de autenticación y firma digital, haciendo que ambas plataformas inter operen en un ambiente SOA y se encarguen cada una de las funcionalidades en las que destacan. En nuestra empresa, VIAVANSI, hemos desarrollado una gran multitud de aplicaciones que se integran con @Firma para la Junta de Andalucía. Quizás podríamos destacar algunas debilidades que bajo nuestro punto de vista hemos advertido en esta plataforma:
- Su matriz de compatibilidad (a día de hoy la última es consultable en este enlace del portal Pluton de la Junta de Andalucía) es relativamente reducida para la Administración Pública, que busca poder dar servicio al 100% de la ciudadanía. Se quedan por ejemplo fuera de ella usuarios de Mac (como el que escribe), hemos observado problemas en función de las versiones de JRE, no hay actualmente soporte de Firefox 3, etc.
- La apariencia (look&feel) del cliente es mejorable.
- Cada aplicación que se integre con @Firma debe disponer en sus librerías del cliente de @Firma, y desarrollar código para utilizar dicho cliente. Ello implica que, cada vez que hay una actualización de este cliente de @Firma, hay que realizar un esfuerzo bastante importante de mantenimiento de aplicaciones para introducir el nuevo cliente, realizar los cambios que sean necesarios, probar y desplegar de nuevo las aplicaciones, etc.
Precisamente, esas debilidades son de hecho puntos fuertes de Viafirma, que la hacen sin duda destacar. Tal vez por ser una plataforma de desarrollo más reciente, Viafirma dispone de una enorme matriz de compatibilidad, pudiendo operar en prácticamente cualquier combinación de sistema operativo / navegador / versión de Java Runtime Environment (JRE) / autoridad de certificación / disposición del certificado (software, tarjeta -DNI electrónico-, token)… Por ejemplo, firma en Mac sin problemas 🙂 Como ejemplo, en las dos primeras semanas de funcionamiento en la aplicación de «Acciones formativas de las Empresas» de la Fundación Tripartita para la Formación en el Empleo se superaron las 300.000 operaciones de autenticación y firma digital sin apenas incidencias. De hecho, el sistema «Acciones formativas de las Empresas» es probablemente, junto a las aplicaciones de Renta de la Agencia Tributaria, la aplicación pública con más operaciones de firma digital de España, ya que prácticamente cualquier empresa española puede ser usuaria del sistema.
Por otro lado, Viafirma incluye un concepto «push» de su cliente de firma, lo cual es una ventaja crucial para la estrategia de mantenimiento de aplicaciones. La librería cliente reside en un único nodo central (servidor de Viafirma), de forma que cuando se libera una nueva versión de dicha librería, solo se debe realizarse la actualización en ese nodo. Todas las aplicaciones que utilicen el cliente quedan en ese momento automáticamente actualizadas, reduciéndose así enormemente el impacto de los nuevos desarrollos. Sin duda se evitan así fallos de actualización difícilmente controlables, redundando finalmente todas estas ventajas en la ciudadanía, que en todo caso es -somos- los usuarios de estos sistemas.
Esta nueva característica de Viafirma 2.2 permite utilizar la plataforma para las operaciones más relacionadas con el usuario de la aplicación (la detección y lectura de certificados, y la operación de firma digital en local). Viafirma se comunica con los API Web Services nativos de @Firma para el resto de operaciones de núcleo: la validación de certificados con las CRL o servicios OCSP de las diversas autoridades de certificación, la custodia de los documentos firmados, etc.
De esta forma, se consigue una integración rápida y no intrusiva en «modo bridge». Se podría decir que Viafirma se encarga de la «capa de cliente» del proceso, interactuando con el usuario y su almacén de certificados, y @Firma se encarga de la «capa de servidor», responsabilizándose de la conexión con las diversas Autoridades de Certificación, la custodia de las firmas (opcionalmente), etc.
Las ventajas de este escenario son así muchas:
- Las instituciones disponen de un cliente de firma universal, que soporta prácticamente cualquier combinación de sistema operativo (Windows, incluyendo incluso la beta de Windows 7, Linux, Mac OS), navegador (Internet Explorer -6, 7 e incluso a nueva versión 8…-, Firefox-incluyendo la versión 3-, Safari, Google Chrome…), versión de JRE (5, 6, etc.), Autoridades de Certificación (FNMT, DNI-e, Camerfirma, ANCERT, Izenpe, Firma Profesional, ANF-AC, etc.), disposiciones (software, tarjeta incluyendo DNI-e, token, etc.)… La matriz de compatibilidad se ve ampliada en una gran magnitud, resultando principalmente favorecida la ciudadanía.
- El cliente de firma de Viafirma soporta incluso la utilización de un certificado exportado en formato P12 (formato de exportación usual en Linux o Mac) o PFX (este último típico de Windows), sin necesidad de importarlo en el almacén de certificados del sistema operativo o navegador. Un típico caso de uso sería, por ejemplo, que tengamos nuestro certificado personal exportado en un pendrive USB y queramos realizar una operación de autenticación o firma digital en un cibercafé, donde tal vez no tengamos permisos para instalar el certificado (o simplemente no lo deseemos por motivos de seguridad). El usuario puede escoger la ubicación del fichero P12 o PFX de una ruta local (como por ejemplo en ese pendrive), y utilizarlo así como si el certificado estuviese instalado en la máquina.
- Se reduce enormemente el coste de mantenimiento de aplicaciones, ya que como se ha comentado anteriormente el cliente de firma solo reside en un nodo central y la actualización de versiones del cliente se realiza de forma automática en las aplicaciones.
- La institución mantiene su instalación de @Firma plenamente operativa, y en ella reside precisamente la responsabilidad de ejecutar operaciones críticas como la validación de los certificados (revocados, caducados, conexión a CRL y servicios OCSP, etc.), custodia de los documentos firmados, y en general, toda la lógica de servidor. Eso sí, la custodia podría ser opcional si se desea que los ficheros y/o sus firmas digitales sean custodiados por la aplicación o incluso por Viafirma, que soporta custodia en sistemas NFS, en ECM como Alfresco, e incluso en campos de base de datos tipo LOB.
- Se crea una disposición plenamente coherente con una política de interoperabilidad entre plataformas basadas en arquitecturas SOA, aprovechando los puntos fuertes de cada una de ellas, dispuestos a modo de servicio.
La nueva versión 2.2 de Viafirma además soporta el formato CMS y el formato 3.1 de factura electrónica e incluye otras actualizaciones menores.