Viafirma 2.2: Soporte de integración con @Firma

15 Abr 2009

Compartelo:Share on Facebook0Share on Google+3Tweet about this on TwitterShare on LinkedIn0

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.

Screenshot de sistema de información utilizando el bridge Viafirma/@Firma

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 un 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 interoperen 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 -DNIe-, 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, sólo 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’s Web Services nativos de @Firma para el resto de operaciones de núcleo: la validación de certificados con las CRL’s o servicios OCSP de las diversas autoridades de certificación, la custodia de los documentos firmados, etc.

Diagrama de arquitectura

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 CA’s, 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.), CA’s (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 ciber-café, 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 sólo 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’s 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’s como Alfresco, y 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-e e incluye otras actualizaciones menores.

Compartelo:Share on Facebook0Share on Google+3Tweet about this on TwitterShare on LinkedIn0

8 Responses to “Viafirma 2.2: Soporte de integración con @Firma”

  1. Jorge Torres Chacón 16 de abril de 2009 at 8:17 #

    En 2 palabras: im-presionante. No es por barrer para casa, pero el equipo de Viafirma está que se sale…

  2. White book 16 de abril de 2009 at 15:41 #

    Yo no pertenezco a VIAVANSI y mi opinión es totalmente neutral.

    Puedo asegurar que entre lo que hay ahora y esta solución no hay color. Se acabaron las incompatibilidades con navegadores, sistemas operativos cliente, usuarios y ciudadanos que no pueden autenticarse o firmar porque no se ha dado la tecla con la instalación de componentes o porque hay algo que no está soportado. ¿Estoy soñando?.

    Felicidades al equipo de Viafirma porque con este trabajo van a ahorrar muchos dolores de cabeza y van a favorecer la implantación y expansión de la administración electrónica.

  3. Emilio 16 de abril de 2009 at 19:15 #

    Hola Javier,

    Hace unos meses participé en la elaboración de un informe en el que se comparaban distintas plataformas y servicios de autenticación y firma electrónica (informe en el que fue incluida viafirma).

    Después de leer el artículo se han confirmado mis sospechas: está solución va por muy buen camino.

    Sin embargo, hay una serie de puntos que considero importantes:
    1. A diferencia de @firma (que usa el estilo de díalogo establecido por el sistema operativo. muy aconsejable en ocasiones), vuestro applet es gráficamente bastante innovador, pero sería de agredecer disponer de varios skins que permitieran buscar el mejor ajuste con la paleta de colores de la web (pasando por ejemplo el nombre del skin como parámetro a la hora de cargar el applet en la página), puesto que el color naranja utilizado puede no ser adecuado en algunos casos. Un skin con los colores predeterminados sería una gran noticia.
    2. Que entre los parámetros que se usan al cargar el applet se incluyera la opción de ejecución en modo debug, donde se visualizará la versión de viafirma, JVM del browser, versión del browser, etc.

    Enhorabuena por la solución.

    Buenas tardes.

  4. Javier Echeverría Usua 16 de abril de 2009 at 20:21 #

    Hola Emilio, te agradezco tus comentarios y sin duda alguna tus propuestas. El tema del skin ciertamente es interesante y creo que técnicamente alcanzable. Por otro lado, el tema del modo DEBUG en ningún caso debería ser problemático, aunque en la propia consola Java del cliente ya se ve parte de la información que comentas, además de que el servidor también captura esta información… pero no deja de ser una opción sencilla e intesante.

    Por cierto, nos hemos visto en varias comparativas por parte de las principales consultoras del país (seguro que se nos vienen a la cabeza)… no sé en cuál participarías, pero sin duda tenemos que agradeceros mucho a todos vosotros por esas excelentes referencias que nos estáis dando, que aúpan día a día al producto y apoyan la evolución de Viafirma. Muchísimas gracias a todos vosotros por confiar en Viafirma y sobre todo, por hacer las comparativas a fondo, basándoos en bases tecnológicas y con independencia.

  5. jorge 21 de abril de 2009 at 10:29 #

    Javier,
    Pienso que en el esquema no estaría de más incluir la posibilidad que tienen las apliaciones de delegar en el componente de VIAFIRMA la posibilidad de hacer la custodia de documentos cuando no quieras hacer la custodia en @firma.
    Al tener una interfaz a implementar se puede elegir una solución contra Alfresco a través de categoría y metadatos que identifiquen la aplicación.

    Por mi parte felcitaros en esta andadura y espero que esa “cultura” de hacer las cosas vaya calando.

    Saludos,

  6. chencho 13 de mayo de 2009 at 10:29 #

    Una solucion sencillamente genial. El unico problema de adaptarse con @firma es que esta no genera una firma valida para las plataformas de verificacion de la FNMT.

    Una pregunta ¿vuestro informe de firma devuelto no proporciona el PCKS7?

  7. Félix García Borrego 14 de mayo de 2009 at 8:59 #

    Hola checho,
    El módulo de integración Viafirma-@Firma está pensado para entidades que ya están “atadas” a @firma. Y desde luego siempre tienes la posibilidad de usar directamente Viafirma sin @Firma y terminar con todos los problemas :p.

    Respecto a permitir exportar el PKCS7 actualmente no se expone. Viafirma fue pensada desde el principio con XADES en mente y este es el formato que se puede recuperar. El formato CMS fue desarrollado precisamente para permitir la integración con @Firma y actualmente no exponemos en el API una forma de recuperarlo. De hecho la implementación de CMS es parcial y “adaptada” a los problemas que tiene @firma en este sentido.

  8. alvaro 27 de mayo de 2009 at 9:52 #

    Hola,

    ¿Vais a publicar estas mejoras en la versión de código abierto?

    Gracias

Leave a Reply

*