Con esta nueva versión, y con el uso del nuevo cliente desarrollado para PHP, se permitirá a los integradores incorporar en sus portales los servicios de Autenticación haciendo uso del DNIe y, por supuesto, del resto de Certificados Digitales que ya veníamos soportando.

En casa ya nos estamos beneficiando de esta nueva versión, integrando nuestras plataformas Moodle (e-learning para uso interno) y Drupal (cms) con Viafirma para autenticarnos con el DNIe. Otros desarrollos específicos en PHP, como TimeTracker (control de imputaciones horarias), también han sido integrados para permitir el acceso mediante DNIe.

Sector Público

Como no podía ser de otra forma, nuestro repaso empezará por la implantación con mayor número de operaciones realizadas, es decir, la implantación de Viafirma en la Fundación Tripartita para la Formación en el Empleo.

Fundación Tripartita

En apenas 10 meses desde su paso a producción, han superado los 2,6 millones de transacciones, entre autenticaciones y firmas, tal y como se resumen en las siguientes gráficas.

Las operaciones fueron realizadas con certificados digitales de varias Autoridades Reconocidas por la plataforma, entre ellas, FNMT, DNIe, Camerfirma, Izempe, Ancert o ANFAC, pero sin duda, el grueso de operaciones fueron realizadas por los certificados de empresa de la FNMT, tal y como se muestra en la siguiente gráfica.

Ratios de Efectividad

Las siguientes gráficas muestran el ratio de efectividad de las autenticaciones y firmas completadas. Si tenemos en cuenta que para estas métricas se tomaron valores de cierre de sesión sin finalizar el proceso de firma o autenticación (por ejemplo, un usuario se autentica en el sistema, y por cualquier motivo ajeno al sistema, decide cerrar sin firmar el documento solicitado), estos resultados demuestran un excelente comportamiento.

Ratio de Efectividad en Autenticaciones

Junta de Andalucía

La Junta de Andalucía está estudiando la utilización de Viafirma como cliente de autenticación y firma digital. Gracias a ese uso la Junta de Andalucía se beneficiaría de la usabilidad y neutralidad tecnológica que caracteriza a Viafirma, tal y como se recoge en nuestra Matriz de Compatibilidad, probablemente una de las más completas del mercado.

Estas implantaciones se sumarían a otras implantaciones en el sector público realizadas en República Dominicana, donde organismos como la Direcc. Gral. de Impuestos Internos (DGII - el equivalente a la Agencia Tributaria), o el Ministerio de Educación Superior, Ciencia y Tecnología (SEESCyT) ya hacen uso de Viafirma para completar transacciones de autenticación y firma mediante el uso de Certificados Digitales reconocidos por el INDOTEL, órgano regulador.

Sector Educativo

A la implantación de Viafirma el año anterior en la Universidad Iberoamericana (UNIBE), en este 2009 se le suman las implantaciones de Viafirma en la Universidad de Extremadura y la Universidad de Cádiz, que dispondrá de un escritorio centralizado de firmas.

Sector Productivo

Toyota España integró su ERP con Viafirma para gestionar la firma electrónica de todas sus facturas, haciendo uso del formato facturae 3.1 que ofrece Viafirma, siendo reconocida por la propia Agencia Tributaria como solución compatible con el formato homologado.

En las Islas Baleares, su Colegio de Farmacéuticos (COFIB), completó la integración con Viafirma de su sistema de gestión para la Receta Electrónica.

Alianzas

En este 2009 afianzamos colaboraciones comerciales y técnicas con la Autoridad de Certificación Firmaprofesional. También extendimos nuestra relación comercial en el mercado latinoamericano, con colaboraciones en Chile, Panamá, Costa Rica y República Dominicana.

Roadmap

En 2010 Viafirma continuará con la incorporación de nuevas funcionalidades, nuevos formatos de firma, nuevas Autoridades de Certificación reconocidas. Las mejoras introducidas durante este año que terminamos, y las que incluiremos en el próximo, sólo son posibles con el apoyo mostrado en todas nuestras implantaciones, también reflejado en los numerosos correos de apoyo y felicitaciones recibidos y, como no, gracias al excelente equipo que hay detrás de Viafirma.

Por todos ellos, gracias y feliz entrada de año 2010 !!

Instalación del driver para lectores que comercializa C3PO.  (Si tu lector no es de C3PO puedes saltar este apartado)Actualmente C3PO comercializa varios tipos de lectores compatibles con libccid (driver ya incluido en MacOS), por lo que podremos utilizarlos en MacOS directamente. Aunque actualmente comercializa varios tipos de lectores, durante las pruebas hemos podido comprobar el correcto funcionamiento del lector LCT31 y del teclado con lector integrado KBR36 sin necesidad de instalación de ningún driver.

Instalación del driver para lectores que comercializa Bit4Id.(Si tu lector no es de Bit4Id puedes saltar este apartado)
En el caso de los lectores comercializados por Bit4Id y en concreto el modelo miniLector ESSENTIA, hemos tenido más problemas ya que los drivers no vienen de serie con MacOS y por otro lado los drivers indicados en la web en http://www.bit4id.com/espanol/descargascontroladores.php  no están actualizados y no funcionan correctamente con las últimas versiones de MacOS. Afortunadamente estos problemas pueden ser solucionados descargando e instalando los drivers oficiales de http://www.acr38u.com/index.php?pos=drivers

Actualización Bit4Id: Aunque las pruebas las hemos realizado sólo sobre un conjunto reducido de lectores (los que teníamos a nuestro alcance), el fabricante Bit4Id nos informa que actualmente disponen de lectores compatibles con libccid como el miniLector Lite, por lo que debería funcionar correctamente sin la necesidad de instalación de drivers.

Instalación del driver para lectores de GEMPLUS.(Si tu lector no es de GEMPLUS puedes saltar este apartado)
Al igual que ocurre con los lectores de C3PO, los drivers necesarios ya están incluidos en MacOS por lo que podremos utilizarlos sin necesidad de ninguna instalación.

Instalar la librería para tarjetas inteligente (OpenSC)(Instalar estas librerías es necesario sea cual sea su lector de tarjetas) Una vez que tengamos instalado el driver para nuestro lector de tarjetas, será necesaria la instalación de la librería OpenSC, y aunque en las nuevas versiones MacOS ya se incorpora, en algunos casos puede ser necesario actualizar estas librerías. En concreto, para poder utilizar el DNIe en nuestro equipo tendremos que instar la versión de sca-0.2.3pre2 en caso de que se trate de un MacOS Leopard 10.5.x o la versión sca-0.2.2 para la versión MacOs Tiger 10.4.x.

Instalar los drivers para el DNIe.(Necesario para hacer uso del DNIe)
En el caso particular del DNIe, también será necesario la instalación del paquete opensc-dnie, que está disponible para su descarga en http://www.dnielectronico.es/descargas/PKCS11_para_Sistemas_Unix/index.html.

Una vez instalado ya podremos hacer uso del DNI electrónico en nuestro equipo.NOTA: Aunque existen versiones más recientes de OpenSC para MacOS, es necesario que se instale exactamente la versión indicada ya que en otro caso obtendremos el siguiente error: load_dynamic_driver: dynamic library ‘/Library/OpenSC/lib/libopensc-dnie.dylib’: invalid module version.Para más información se puede consultar el manual de instalación oficial del dnie.

Probamos nuestro nuestro lector con Viafirma
Para ello, con el DNIe ya introducido en nuestro lector, accedemos con Safai o Firefox a la demo de Viafirma .

1. ¿He bloqueado mi DNIe? En el portal oficial del DNI electrónico han publicado unas herramientas que comprueban si tu DNIe aún tiene disponible algún intento de introducir el PIN de acceso.    Como no podía ser de otra forma, la herramienta que ponen a disposición de los usuarios sólo está disponible para plataformas Windows, por lo que los demás nos quedamos a cuadros :( Si algún usuario de windows lo desea averiguar, el enlace es el siguiente http://www.dnielectronico.es/como_utilizar_el_dnie/ComprobacionBloqueoPIN.pdf

y para los demás (supongo que el resto de usuarios somos conscientes de cuándo hemos bloqueado nuestro PIN :) ), no nos queda otra que aplicar el procedimiento establecido para el desbloqueo del DNIe.

,

 2.  Efectivamente, soy un muñón, y he bloqueado mi DNIe. Tendrás que acudir a la comisaría más cercana y, através de los  TERMINALES habilitados para tal efecto procederemos al desbloqueo.           

1.  Introducimos nuestro DNIe.
2. Nos pedirá la contraseña, pero optaremos por la opción “Olvidé mi contraseña”.
3. Inmediatamente después, el terminal nos solicitará nuestra identificación biométrica, esto es, a través de nuestra huella digital.
4. Para ello, sólo tenemos que seguir los pasos que nos indicará el terminal y concluiremos indicando una nueva contraseña.

   Bueno, ya no tenéis excusas para no usar vuestro DNIe con VIAFIRMA !!

Este artículo pretende ser una guía rápida qué explique cómo realizar una operación de autenticación con Viafirma, de cara a obtener los datos del certificado digital del usuario.

Aunque Viafirma ofrece todos sus servicios mediante métodos estándar (Servicios Web y OpenID), también disponemos  de un cliente para Java que permite de una forma muy sencilla integrar aplicaciones desarrolladas en esta tecnología con los servicios que ofrece Viafirma.

En este artículo mostraremos cómo añadir las dependencias necesarias a un proyecto web Java para hacer uso de los diferentes servicios de firma digital (XAdES, Facturae, PDF sign, etc… ), autenticación (FNMT, Camerfirma, Firma profesional, Ancert, ACA, Izempe,  DNIe, etc…),  custodia (integridad, etc…)  y verificación (CRLS, OCSP, etc…).

El procedimiento sería el siguiente:

1.- Añadir las dependencias

Viafirma está preparado para trabajar con Maven; en este tipo de proyectos sólo será necesario añadir la dependencia a viafirma-client de la siguiente manera:

<!--  Dependencias para el cliente viafirma con soporte de OpenID -->
<dependency>
 <groupId>org.viafirma</groupId>
 <artifactId>viafirma-client</artifactId>
 <version>[2.2.3,2.3.0)</version>
</dependency>

Y poner el repositorio de librerías de VIAVANSI para poder recuperar esta librería:

http://repositorio.viavansi.com/repo

Si el proyecto no está basado en Maven, necesitaremos añadir manualmente los .jar que se incluyen en el directorio dependency dentro del distribuible de viafirma-client.

2.- Crear la página de acceso a la autenticación

A modo de ejemplo básico vamos a crear una jsp que inicialice el cliente de Viafirma y permite al usuario iniciar el proceso de autenticación pulsando en un enlace. Este cliente utilizará el servidor público de pruebas de Viafirma desplegado en las instalaciones de Viavansi.

<%@page import=“org.viafirma.cliente.ViafirmaClientFactory”%>
<%@page import=“org.viafirma.cliente.ViafirmaClient”%>
<body>
<%
if (!ViafirmaClientFactory.isInit()) {
 // Configuración básica del cliente.
 ViafirmaClientFactory.init(“http://viafirma.viavansi.com/viafirma”,“http://viafirma.viavansi.com/viafirma”);
}
if(request.getParameter(“autenticar”)!= null){
 ViafirmaClient viafirmaClient = ViafirmaClientFactory.getInstance();
  // Iniciamos la autenticación indicando la uri de retorno. 
 viafirmaClient.solicitarAutenticacion(request, response,“/viafirmaClientResponseServlet”); }
%>
<p><a href=“?autenticar=true”>Solicitar autenticación</a></p>
</body>

Cuando el usuario pulse sobre el enlace “Solicitar autenticación” el usuario será redirigido a Viafirma, donde se le solicitará su certificado digital. Viafirma validará y tratará el certificado del cliente y retornará el resultado de la autenticación a la aplicación cliente que estamos desarrollando. En la jsp de ejemplo le indicamos a Viafirma que la url de retorno (donde Viafirma debe mandarnos el resultado de la autenticación) es /viafirmaClientResponseServlet .

3.- Procesar la respuesta

Una vez que Viafirma obtenga la información contenida en el certificado digital, retornará los datos a la url que la aplicación cliente le indicó, por lo que el siguiente paso será definir un servlet (cuya URL en este ejemplo es /viafirmaClientResponseServlet) que se encargue de gestionar la respuesta. Para ello crearemos un servlet que extiende de org.viafirma.client.ViafirmaClientServlet, e implementaremos los métodos error(…), cancel(…) y authenticateOK(…):

public class ViafirmaClientResponseServlet extends ViafirmaClientServlet{
 @Override
 public void authenticateOK(UsuarioGenericoViafirma usuario,HttpServletRequest request, HttpServletResponse response) {
  // Lógica específica de la aplicación para gestionar el resultado de la autenticación 
  request.setAttribute(“usuarioAutenticado”, usuario);
  request.getRequestDispatcher(“/resultadoAutenticacion.jsp”).forward(request, response);
 }
 @Override
 public void cancel(HttpServletRequest request, HttpServletResponse response) {
   // Gestiónn de cancelaciónn del usuario al autenticar o firmar
   request.setAttribute(“error”, “El usuario ha cancelado la autenticación”);
   request.getRequestDispatcher(“/resultadoAutenticacion.jsp”).forward(request, response);
 }
@Override
public void error(CodigoError codError, HttpServletRequest request, HttpServletResponse response) {
  // Gestión de error al autenticar o firmar 
  request.setAttribute(“codError”, codError); 
 request.getRequestDispatcher(“/resultadoAutenticacion.jsp”).forward(request, response);
 }
}

En este ejemplo vemos un ejemplo de implementación, en el que la aplicación simplemente guarda en request el objeto UsuarioGenericoViafirma que contiene todos los datos que aparecen en el certificado digital. Obviamente cada aplicación, en función de su lógica de negocio, deberá realizar la implementación específica que requiera.

4.- Adaptar la plataforma al skin de la aplicación cliente.

La página donde se solicita el certificado digital reside en Viafirma. Sin embargo, a través de CSS podremos conseguir que el usuario no aprecie un cambio de interfaz, de forma que el salto de la aplicación a Viafirma parezca transparente a nivel estético.

Para hacer que Viafirma se adapte fácilmente al estilo visual de nuestra aplicación cliente, sólo tendremos que colocar el fichero viafirmaStyle.css en el raíz de nuestra aplicación y redefinir el aspecto visual de la interfaz  de Viafirma.

5.- Descarga el cliente y pruébalo tu mismo

Descargar ejemplo de autenticación utilizando el cliente Java para obtener los datos del certificado digital.

Próximamente: Java / JEE : Firma digital XADES y facturae con Viafirma (II)

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.

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.

Viafirma ya soporta la autenticación y firma digital con el nuevo Internet Explorer 8, del mismo modo que es 100% compatible con las versiones beta publicadas de Windows 7.

Adjuntamos una captura de pantalla con una operación satisfactoria de firma realizada sobre este navegador.

(more…)

Para las pruebas se han realizado firmas en servidor XADES de ficheros xml de 20k, utilizando como sistema de custodia ficheros y firmando con un certificado de Firma Profesional en software.

Se han realizado en dos tipos de entornos, el primero bastante precario en recursos y el segundo un entorno de producción real. En ambos casos pudimos comprobar que el comportamiento de Viafirma, ante un gran numero de peticiones fue más que aceptable.

Rendimiento de Viafirma con los requisitos Mínimos de Hardware

El entorno donde se realizaron las pruebas  es un portátil con un procesador Turion a 2 GHz y 2 gigas de RAM, con el servidor de aplicaciones  configurado para permitir 200 hilos concurrentes y con un máximo de 512 MB asignados.

Las pruebas se realizaron configurando un grupo de hilos simulando 100 peticiones por segundo en un bucle infinito.

A continuación se muestran los resultados obtenidos en la misma máquina y misma configuración en un entorno Windows y en un entorno Linux.

Pruebas sobre Windows XP SP 3 en JRE 6.0.11 de Sun

Como se observa en la gráfica, Viafirma mantuvo la cantidad constantes de 1.200 peticiones por minuto con una media de cerca de 5 segundos desde la entrada de la petición hasta su resolución y respuesta.  Mientras se realizaros las pruebas, Jconsole marcó en todo momento un consumo de memoria estable.

Pruebas sobre Ubuntu 8.10 en JRE 6.0.10 de Sun

Repetimos las pruebas en un entorno Unix, y observando que el rendimiento es algo mayor. Respondiendo una media de 2.100 peticiones por minuto.

Rendimiento de Viafirma con la configuración de Hardware recomendada

Después de haber hecho estas pruebas “de andar por casa”, hemos repetido la misma batería de pruebas sobre un entorno de producción, un  Ubuntu Server con 8 nucleos, 6 Gb de memoria y una configuración optimizada de la JVM 6.

Como podemos observar,  el comportamiento es excelente, alcanzando casi más de 7.500 firmas por minuto, manteniéndose totalmente estable la JVM y con el procesador nunca superando el 50% ( debido a los tiempos de espera impuestos por la red).