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.

Con motivo de la implantación de nuestra plataforma de Autenticación y Firma Digital VIAFIRMA en la Universidad de Extremadura, los días 17 y 18 de febrero de 2010 se celebraron dos jornadas de formación, cubriendo entre ambas la capacitación a los perfiles Usuarios y Técnicos-Integradores. Esta implantación se suma a la ya realizada en la Universidad Iberoamericana, y próximamente lo hará con la Universidad de Cádiz.

A punto de finalizar este 2009, queremos hacer un repaso de los logros obtenidos por VIAFIRMA en las implantaciones de este año que estamos a punto de terminar.

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 !!

Parecerá una tontería, pero entre más de 10 millones de DNIe emitidos en España, desbloquearlo puede resultar una  tarea a la orden del día. En la página oficial apenas hay una breve mención del procedimiento, y desde Xnoccio queremos acercar a nuestros lectores esta sencilla tarea.

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 !!

Poca explicación ante un claro ejemplo de cómo desprestigiar a la competencia con detalles como el que os muestro, realmente muy cómico.

Desde un sistema MAC OS, conectaros a cualquier dispositivo de red y comprobad cómo representa el sistema al equipo al que os habéis conectado.

Conexión a otro equipo mac o linux

Conexión a un equipo windows: CRT obsoleto y con el famoso pantallazo azul

Hacía más de un año que sabía de la decisión que adoptó Airbus para incorporar Linux a sus super A380, pero no sabía que en los pequeñitos, como el A319 también lo podría encontrar.

Con esta y otras sorpresas volé hasta Bogotá; la verdad es que me hubiera gustado contarle a todo el mundo esta historia de otra manera, pero la realidad fue que en un viaje de 2 horas y 15 min. de duración el sistema se cayó en cuatro ocasiones, incluyendo reinicio general del sistema. Obviamente, en un vuelo tan corto no te da tiempo ni a ver una peli, pero si hubiera sido así….ejemm.

La solución adoptada (por lo que pude ver en la consola mientras se reiniciaba :) ) es una adaptación de RedHat.

Por cierto, también me llevé una grata sorpresa al comprobar que cada asiento dispone de una salida USB y, aunque no pude comprobarlo, supongo que estará como salida para cargar dispositivos como el iPod.

Bien por Airbus.

Superada la cifra de 7 millones de DNI electrónicos en España, hemos sido testigos de cómo hemos alcanzado también el final de una etapa, la emisión del último DNI tradicional.

El último DNI sin “chip”, tal y como lo publica el país en este artículo, fue emitido a un afortunado ciudadano de un pueblo madrileño que podrá conservarlo como un buen objeto de coleccionistas.

Dos años han transcurrido desde la puesta en marcha del programa DNIe, y desde entonces hemos disfrutado de la incorporación paulatina de numerosos servicios basados en su uso, como la autenticación en algunos bancos.

Y más de un año desde que publicáramos este post donde anunciábamos la primera plataforma openSource con soporte para el DNIe, Viafirma.

A continuación vamos a explicar cómo aprovechar las bondades de tres componentes habituales en nuestros desarrollos para implementar un sencillo flujo de firma de formularios.

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.

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.

Normalmente, para tareas de desarrollo hacíamos referencias a servidores Oracle que teníamos en nuestra propia red local o incluso en nuestro propio equipo (XE - express edition). Pero distinto es cuando pasamos una aplicación a producción y no tenemos a ese maravilloso DBA que te soluciona la papeleta cuando te encuentras con algo que se sale de lo normal en tus desarrollos.

En este caso ese maravilloso DBA estaba buscando papas en la playa, pero afortunadamente mr. google estaba ahí para solucionarnos la papeleta. Por ello, dejo aquí estos fragmentos de código como referencia rápida en futuras conexiones a Clusters de Oracle.

Llamada stand-alone (sin cluster ni nada raro)


url="jdbc:oracle:thin:@192.168.1.2:1521:DEV"


Llamada a un cluster de Oracle con Balanceo de Carga


url="
jdbc:oracle:thin:@(DESCRIPTION=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=myserver01)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=myserver02)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=my_orasrv)))"


donde myserver01 y myserver02 son las IP virtuales de los nodos montados. Y así con todos los nodos que tuviera el cluster. Esto lo encontramos en el foro de Sun http://forums.sun.com.

Cluster sin Balanceo de Carga

url=”jdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=cluster_alias)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=my_orasrv)))”

donde invocan al cluster mediante su alias. Esta otra la encontramos en el foro de www.oraFAQ.com