Xnoccio

En los próximos días liberaremos nueva versión 2.5 de Viafirma caracterizada, principalmente, por el soporte para PHP y mejoras en el proveedor de servicios OpenID. Fueron constantes las peticiones y consultas recibidas por clientes en las que necesitaban de una Autenticación basada en el uso del DNIe desde portales públicos o restringidos (intranet) desarrollados éstos en PHP.

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.

E3L son las siglas de Environmental Electronic Exchange Language y nace ante la necesidad de establecer un formato estándar de intercambio de datos ambientales entre las distintas comunidades autónomas. Se trata de un proyecto colaborativo, en el que las AA PP implicadas consensúan los flujos de información y los plasman en un lenguaje común con unas reglas definidas y aceptadas por todos. E3L proporciona no sólo las reglas para comunicar plataformas tecnológicas, sino que conforma el primer diccionario electrónico de datos ambientales (metadatos). E3L cubre por ejemplo la presentación telemática de la Memoria Anual de Gestores de residuos, la Declaración Anual de Productores de residuos, los Documentos de Control y Seguimiento de residuos, etc. Para más información sobre este proyecto se pueden visitar los portales del proyecto:

• http://www.e3l.es/
• http://www.eterproject.org/

La Consejería de Medio Ambiente de la Junta de Andalucía ha apostado fuerte por la iniciativa y como resultado de ello confió en VIAVANSI para construir Augi@s, un sistema integral de gestión de residuos pionero al hablar E3L. Augi@s permite completar el ciclo de un documento desde su creación hasta su presentación y firma. El sistema ha sido diseñado para hablar en lenguaje E3L; por ello, el equipo de proyecto, constituido por personal de la Consejería de Medio Ambiente y de VIAVANSI, ha participado en la definición del estándar durante su desarrollo. Esto supone al fin una garantía de futuro para el formato de los datos manejados por Augi@s.La aplicación está diseñada con la máxima flexibilidad posible, externalizando en un API independiente la gestión del formato E3L, permitiendo adaptarse a los cambios del mismo en poco tiempo, o integrar nuevos elementos como los servicios publicados en E3S, que ya se encuentran en fase de pruebas en Augias.Considerando la aceptación del formato E3L a nivel estatal y la posibilidad de exportar dicho formato a otros países de la UE, podemos decir que la plataforma Augi@s se encuentra en una posición privilegiada de cara al futuro y vuelve a demostrar que, en contra de lo que se supone en varios círculos de opinión, Andalucía suele liderar a nivel nacional la innovación en muchos proyectos tecnológicos.

Este post no pretende ser más que una ayuda en castellano (encontrable vía Google) para aquellos que se encuentren con este problema en el futuro, ya que hemos encontrado bastantes referencias, pero pocas respuestas.

Los antecedentes

Nos encontrábamos en las instalaciones de un cliente, en un equipo Windows XP al cual le habíamos montado un kit de desarrollo completo: Eclipse (con diversos plugins), Maven, JDK, Tomcat’s de diversas versiones, etc., que tenía que integrarse con Hudson. En ese momento estábamos probando Maven sobre un sencillo proyecto de ejemplo; Maven debía descargar de un repositorio de librerías Artifactory recién descargado. Pero nos encontramos con efectos bastante raros:

• Al hacer un ‘mvn eclipse:eclipse’ en consola, observábamos que todos los JAR’s descargados daban un error de verificación de checksum.  Es decir, parecía ser que el contenido del JAR descargado no era exactamente el esperado. Y además no conseguíamos cargarnos la librería jline, una de las dependencias de las librerías de Plexus. Raro raro, porque nunca habíamos visto ese error. ¿Estaba pasando algo en algún repositorio público?
• Al hacer un’mvn clean’, algo mucho más raro todavía. Veíamos un log extrañísimo de repente saltaba un applet en pantalla que nos pedía confirmación de una operación. ¡Este plugin Maven nuevo!

Las pesquisas

Evidentemente aquí hay algo raro. En el log Maven aparecen mensajes que no habíamos visto hasta ahora:

Downloading: http://sanisidro:8080/artifactory/public/org/apache/maven/shared/ma
ven-shared-io/1.1/maven-shared-io-1.1.jar
116K downloaded
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'e67415a960
00a3110c7834caa325d965022491f6'; remote = '02e1d57be05ecac7dbe56a3c73b113e98f222
40f' - RETRYING
Downloading: http://sanisidro:8080/artifactory/public/org/apache/maven/shared/ma
ven-shared-io/1.1/maven-shared-io-1.1.jar
116K downloaded
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'e67415a960
00a3110c7834caa325d965022491f6'; remote = '02e1d57be05ecac7dbe56a3c73b113e98f222
40f' - IGNORING
[INFO] [clean:clean]
Current policy properties:
mmc.sess_pe_act.block_unsigned: false
window.num_max: 5
jscan.sess_applet_act.sig_trusted: pass
file.destructive.state: disabled
jscan.sess_applet_act.block_all: false
window.num_limited: true
jscan.sess_applet_act.unsigned: instrument
mmc.sess_pe_act.action: validate
jscan.session.daemon_protocol: http
file.read.state: disabled
mmc.sess_pe_act.block_invalid: true
mmc.sess_pe_act.block_blacklisted: false
net.bind_enable: false
jscan.session.policyname: TU1DIERlZmF1bHQgUG9saWN5
mmc.sess_cab_act.block_unsigned: false
file.nondestructive.state: disabled
jscan.session.origin_uri: http://repo1.maven.org/maven2/org/apache/maven
/shared/file-management/1.2/file-management-1.2.jar
mmc.sess_cab_act.action: validate
net.connect_other: false
jscan.session.user_ipaddr: 127.0.0.1
jscan.sess_applet_act.sig_invalid: block
mmc.sess_cab_act.block_invalid: true
thread.thread_num_max: 8
jscan.sess_applet_act.sig_blacklisted: block
net.connect_src: true
thread.thread_num_limited: true
jscan.sess_applet_act.stub_out_blocked_applet: true
mmc.sess_cab_act.block_blacklisted: true
jscan.session.user_name: 127.0.0.1
thread.threadgroup_create: false
file.write.state: disabled
-->> returning Frame NULL
BaseDialog: owner frame is a java.awt.Frame

Empezamos a pensar. Tras unos minutos de desconcierto, eso de jscan huele a antivirus. A ver si está haciendo algo, modificando los JAR’s al descargarlos, modificando alguna Java Policy, modificando la JDK, o incluso interactuando con las políticas de seguridad en runtime… efectivamente, buscando en Google nos lleva a comprobar que el culpable parece ser el antivirus de Trend Micro. Debe estar colocando el applet Java como medida de seguridad, interceptando el código original. El antivirus ha debido pensar que el JAR es un applet y, como hace operaciones de disco (un ‘mvn clean’ debe borrar ficheros), pide permiso. Pero, ¿qué y cómo lo está haciendo? Realizamos unas cuantas tareas:

• Paramos todos los servicios del antivirus. Probamos, sigue fallando. Este antivirus es un poco retorcido, ha debido modificar la JVM o alguna Java Policy.
• Restauramos la JVM, nos aseguramos de estar utilizando lo mismo. Sigue fallando, con el antivirus parado… ¿qué pasa aquí? ¿Dónde está la coleta de este Sansón de la seguridad?
• Probamos el applet de firma de Viafirma, que tampoco funciona. En la Java console observamos un error de un paquete com.trend (si al menos funcionara bien!)… El error era “Exception at com.trend.iwss.jscan.appscan.runtime …”. Nos bajamos el JAR de firma, lo descomprimimos y ¡voilá! Hay un buen conjunto de paquetes nuevos dentro de JAR. El antivirus modifica los JAR’s, lo cual explica todo: el misterioso applet del mvn clean, la rotura del applet de viafirma, los fallos de checksum… pero ¡el antivirus está apagado! ¿Cómo lo hace?

Las conclusiones

Si el antivirus en local no es culpable, debe haber un antivirus a nivel de red, junto al proxy. Efectivamente. El cliente, que por fortuna es técnico y de los que programan, no de los que sólo hablan, nos confirma que en muchas ocasiones ha tenido que utilizar otro proxy para descargarse JAR’s. El invento enemigo de los JAR’s no afecta sólo a Maven, obviamente, sino a cualquier JAR descargado por un proxy que disponga de este mecanismo de seguridad, y que realice determinadas operaciones. De hecho la librería JLine era parada por este producto llamado “Trend Micro InterScan Web Security Suite” que, de hecho, publicita este servicio tan majo y maligno a la vez.

Así que si en algún momento os encontráis este tipo de errores tan extraños, ya tenéis otra posibilidad latente.

El epílogo

Nos cambiamos de proxy y todo fue bien, previa limpieza del repositorio de librerías Maven.

En este artículo muestran los pásos a seguir para utilizar los servicios de firma digital ( XAdes, Facturae, …), autenticación (FNMT, Firma Profesional, ANCERT, …) y verificación de validez de certificados ( OCSP, CRLs, …) desde aplicaciones ASP.NET gracias a Viafirma.

1- Añadir las dependencias necesarias

Es necesario que incorporemos al proyecto las siguientes dlls incluidas en el kit de desarrollo de Viafirma:  DotNetOpenId.dll, log4net.dll y ViafirmaClientDotNet.dll.

Por otro lado también necesitaremos añadir el  directorio “viafirma” y que contiene los ficheros:

• Default.aspx: con los métodos que deben ser sobreescritos con el comportamiento específico a ejecutar cuando finalice el proceso de firma.
• viafirmaStyle.css: con la apariencia que viafirma adoptara para el proceso de autenticación o firma. Este css puede ser adaptado a la identidad corporativa de la aplicación cliente.
• xrds.aspx: necesario para el correcto funcionamiento de la comunicación OpenID.

2- Creamos una página de ejemplo desde la que realizar la firma

Creamos una primera página aspx en la que simplemente colocaremos un botón de acción asociado a un controlador de página que utilizará el API de Viafirma para firmar digitalmente un fichero de ejemplo con el certificado digital al usuario.

El código de la aplicación de ejemplo queda como el siguiente:

<%@ Page Language=”C#” Inherits=”AplicacionEjemploClienteViafirma.Default” %>
<html>
<body>
<h2>Ejemplo de integración Viafirma con .Net</h2>
<form id=”form1″ runat=”server”>
<p>Pruebe la autenticación</p>
<asp:button id=”firmarButton” runat=”server” text=”Firmar un documento de ejemplo con Viafirma” onClick=”FirmarButton_Click” />
</form>
</body>
</html>

3- Implementar el método  FirmarButton_Click

En este método simplemente indicaremos al cliente de viafirma cuál es la url pública de acceso a Viafirma, cuál es la url de acceso al servicio web de Viafirma, y registraremos un fichero para su firma.

public void FirmarButton_Click(object sender, EventArgs e){

    // Configuramos el cliente de viafirma ( En una aplicación real esto se realiza al iniciar la aplicación)
    ViafirmaClientFactory.Init(“http://viafirma.viavansi.com/viafirma”, http://viafirma.viavansi.com/viafirma);
    // Recuperamos / Generamos el contenido del documento a firmar. ( Como ejemplo generamos un txt ) 
    byte[] datos_a_firmar = System.Text.ASCIIEncoding.ASCII.GetBytes(“Contenido del documento firmado”);
    // Enviamos a firmar el documento
     ViafirmaClient clienteViafirma = ViafirmaClientFactory.GetInstance();
    // Registramos el documento que deseamos firmar. Obteniendo un identificador temporal.
    string idTemporalFirma = clienteViafirma.PrepareFirmaWithTypeFileAndFormatSign(“FicheroEjemplo.txt”, typeFile.txt, typeFormatSign.XADES_EPES_ENVELOPED, datos_a_firmar);
    System.Console.Write(“idTemporalFirma: “ + idTemporalFirma);
    // Iniciamos el proceso de firma redireccionando al usuario a Viafirma interactuando con el usuario..
    clienteViafirma.Sign(idTemporalFirma);
}

    

Con este simple código ya conseguimos que nuestra aplicación ASP.NET utilice Viafirma para que sea ésta la responsable de solicitar, validar, recuperar el certificado o DNI electrónico del usuario y firmar el documento digitalmente.  En este ejemplo se ha realizado la firma de un fichero de texto utilizando en formato XADES, pero de una forma muy similar se podría haber optado por realizar la firma de un pdf o de una factura electrónica.

Una vez que el proceso termine, Viafirma devolverá el control a la aplicación ASP.NET retornando todos los datos obtenidos del certificado, junto con el identificador de firma asociado al documento firmado.

Obtener los datos de respuesta

Una vez que Viafirma obtenga los datos del certificado de usuario invocará al método ProcessResponseSign, que se encuentra en el fichero Default.aspx dentro del directorio viafirma. Lo único que tendremos que hacer es sobreescribir dicho método con el comportamiento deseado y recuperar todos los datos de la firma del objeto FirmaInfoViafirma.
En este ejemplo, si la firma ha sido correcta, redireccionamos al usuario a una página de destino.

override public void ProcessResponseSign(Viafirma.Estado estado,Viafirma.FirmaInfoViafirma firma){

    Viafirma.Log.Debug(“Firma Viafirma realizada correctamente.”);
    // Aquí ya tenemos todos los datos asociados al cliente y a su firma.    
    //redireccionamos al usuario a la p gina destino considerando el usuario ya ha finalizado la firma.
    if(Viafirma.Estado.OK== estado){
       Session[“resultadoFirma”]= firma;
       Uri url=new Uri(HttpContext.Current.Request.Url, HttpContext.Current.Response.ApplyAppPathModifier(“~/resultadoFirma.aspx”));
       HttpContext.Current.Response.Redirect(url.AbsoluteUri);
    } else{
      // Hay problemas al firmar.
    }
}

A continuación se muestran algunas capturas de pantalla de la aplicación de ejemplo ASP.NET en acción:

Página inicial de la aplicación de ejemplo: ( contenida en el Kit de desarrollo de Viafirma)

La aplicación ASP.NET interactuando con Viafirma para realizar la firma.

La aplicación ASP.NET muestra algunos de los datos retornados tras el proceso de firma.

Aunque Viafirma ofrece todos sus servicios mediante métodos estándar ( Servicios Web y OpenID), hemos desarrollado un cliente para .Net 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 dlls necesarias al proyecto y cómo hacer uso de los diferentes servicios de firma digital (XAdES, Facturae, PDF sign, etc… ), autenticación (FNMT, Camerfirma, Firma profesional, DNIe, etc…),  custodia (integridad, etc…)  y verificación (CRLS, OCSP, etc…).

1- Añadir las dependencias necesarias

Es necesario que incorporemos al proyecto las siguientes dlls incluidas en el kit de desarrollo de Viafirma:  DotNetOpenId.dll, log4net.dll y ViafirmaClientDotNet.dll.

Por otro lado también necesitaremos añadir el  directorio “viafirma” y que contiene los ficheros:

• Default.aspx: con los métodos que se ejecután cuando el proceso de autenticación o firma finalice.
• viafirmaStyle.css: con la apariencia que viafirma adoptara para el proceso de autenticación o firma.
• xrds.aspx: necesario para el correcto funcionamiento de la comunicación OpenID.

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

Creamos una primera página aspx en la que simplemente colocaremos un botón de acción asociado a un controlador de página que utilizará el API de Viafirma para autenticar con certificado digital al usuario..

El código de la aplicación de ejemplo queda como el siguiente:

<%@ Page Language="C#" Inherits="AplicacionEjemploClienteViafirma.Default" %>
<html>
<body>
<h2>Ejemplo de integración Viafirma con .Net</h2>
<form id="form1" runat="server">
<p>Pruebe la autenticación</p>
<asp:button id="autenticarButton" runat="server" text="Autenticar al usuario con certificado o dnie" onClick="autenticarButton_Click" />
</form>
</body>
</html>

3- Implementar el evento  autenticarButton_Click

En este método simplemente indicaremos al cliente de viafirma cuál es la url pública de acceso a Viafirma y cuál es la url de acceso al servicio web de Viafirma.

public void autenticarButton_Click(object sender,EventArgs e){
    // Configuramos el cliente de viafirma ( En una aplicación real esto se realiza al iniciar la aplicación)
    ViafirmaClientFactory.Init("http://pruebas.viavansi.com/viafirma","http://pruebas.viavansi.com/viafirma");
    // Obtenemos una instancia del cliente e iniciamos la autenticación
   ViafirmaClient clienteViafirma=ViafirmaClientFactory.GetInstance();
   clienteViafirma.Autenticate();
}

Con este simple código ya conseguimos que nuestra aplicación ASP.NET utilice Viafirma para que sea ésta la responsable de solicitar, validar y recuperar el certificado o DNI electrónico del usuario. Una vez que el proceso termine, Viafirma devolverá el control a la aplicación ASP.NET retornando todos los datos obtenidos del certificado.

Obtener los datos de respuesta

Una vez que Viafirma obtenga los datos del certificado de usuario invocara al método ProcessResponseAutenticacion, que se encuentra en el fichero Default.aspx dentro del directorio viafirma. Lo único que tendremos que hacer es sobreescribir dicho método con el comportamiento deseado y recuperar todos los datos del certificado del objeto UsuarioGenericoViafirma.
En este ejemplo si la autenticación ha sido correcta redireccionamos al usuario a una página de destino.

override public void ProcessResponseAutenticaction(Viafirma.Estado estado,Viafirma.UsuarioGenericoViafirma usuario){
    Viafirma.Log.Debug("Autenticación Viafirma realizada correctamente. Resultado:"+ estado);
    // Aquí ya tenemos todos los datos asociados al cliente. y redireccionar al usuario a la página destino
    // considerando el usuario ya autenticado.
    if(Viafirma.Estado.OK== estado){
        Session["resultadoAutenticacion"]= usuario;
        Uri url=new Uri(HttpContext.Current.Request.Url, HttpContext.Current.Response.ApplyAppPathModifier("~/resultadoAutenticacion.aspx"));
        HttpContext.Current.Response.Redirect(url.AbsoluteUri);
    }else{
        // Hay problemas al validar.
    }
}

Próximamane: C# / ASP.NET : Firma digital y autenticación con Viafirma (II)

No es noticia que te fastidien una aplicación que estaba corriendo bien porque otro servicio anda por ahí haciendo de las suyas y tú eres el último en enterarte.

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.