Xnoccio.com

La nueva versión de Viafirma, coincidiendo con su instalación en dos importantes entidades bancarias,  ofrece soporte oficial para Oracle WebLogic 11. De esta forma, junto con las plataformas ya soportadas por Viafirma (Tomcat 5, Tomcat 6, Websphere, etc…), ahora se incluye:

• Oracle Fusion Middleware 11 / Weblogic 11g.
• Oracle Enterprise Pack for Eclipse
• Sun JVM 5, Sun JVM 6
• SO: Linux,  Windows Server

El proceso de instalación es muy sencillo,  por lo que siguiendo los pasos del manual de instalación de Viafirma para Weblogic podremos disponer de sus servicios de autenticación (DNIe o cualquier otro certificado digital) y firma digital (XAdES, PAdES, CMS, CAdES, facturae, firma en lotes,…) desplegados sobre Weblogic .

Hace algunos días que Viafirma tiene su canal twitter. Invitamos a todos los interesados en la plataforma a seguirnos por esa vía, donde intentaremos dar primicias, anunciar liberaciones de versiones, etc.

En Viavansi hemos desarrollado un nuevo módulo para Drupal que permite la autenticación de usuarios mediante el DNIe y otros certificados digitales. Aprovechando el soporte de Viafirma para el protocolo de intercambio de identidades OpenId, la integración entre Drupal y nuestra Plataforma de Autenticación y Firma Digital ya es posible.

En este artículo, explicaremos cómo conseguirlo a través de esos sencillos pasos.

Primer Paso: descarga el módulo

En el siguiente enlace podrás descargar el nuevo módulo de autenticación para Drupal: viafirma-drupal-1.0.zip

Segundo Paso: instala tu módulo

Copia el módulo Viafirma en la carpeta /sites/all/modules. Recuerda que para ello, deberás tener permisos de escritura.

Tercer Paso: configura tu módulo

Una vez instalado deberás acceder a tu Drupal como Administrador para poder activar el nuevo módulo Viafirma.

Activa el Módulo

Configura el Módulo

Cada parámetro está comentado o dispone de valores ejemplos. También podrás acceder a la ayuda de configuración de viafirma, con información útil sobre el estado de la instalación del módulo.

Cuarto Paso: configura tus usuarios

La gestión de usuarios mantendrá el método user/password, por lo que éstos podrán seguir manteniendo esta forma de autenticación. Para aquellos que deseen autenticar con su DNIe u otro tipo de certificado, deberán asegurarse que su userid sea su número de DNI/NIE. En resumen, la instalación de este nuevo módulo te permitirá un doble método de autenticación: user/password y DNIe/certificados digitales.

Con el nuevo módulo, los usuarios tendrán un nuevo método de autenticarse, pudiendo hacerlo con su DNIe o con cualquier de los certificados soportados por Viafirma en estos momentos.

Ahora, toda la responsabilidad recae en Viafirma, encargándose ésta de recuperar el certificado del usuario (en cualquier formato, software (.p12, .pfx) o hardware (smartCard, DNIe, token), validar su estado y, en caso de una validación satisfactoria, devolver a Drupal el identificador del usuario, en este caso, su DNI o NIE.

Como resultado, nuestros usuarios perfectamente autenticados en Drupal.

Si ya usas Viafirma, y cuentas con portales desarrollados con Drupal, ahora es el momento de incorporar la autenticación con DNIe que necesitabas.

Próximamente, firmando documentos desde Drupal con tu DNIe.

Es de todos conocidos los grandes beneficios de usar una Wiki, para tener organizado y actualizado una gran cantidad de información y contenido, de forma que pueda ser rápidamente consultada y actualizada. Sin ninguna razón especial más allá de la simple curiosidad, vamos a poner como ejemplo en este caso una “implementación” wiki basada en Java (XWiki) y vamos a conseguir de forma sencilla que los usuarios puedan logarse con su Certificado Digital o DNI electrónico (DNIe).

Como no podría ser de otra forma, vamos a hacer uso del servicio de autenticación de la plataforma Viafirma, sirviéndonos de su cliente de autenticación, apoyándonos en su espectacular matriz de compatibilidad, además mantendremos el acceso por usuario/contraseña habitual de XWiki. Para realizar esta integración nos hemos basado principalmente en la documentación que podemos encontrar en las páginas oficiales de ambas plataformas, por un lado tenemos a Viafirma y por otro lado la web para desarrolladores de XWiki Development Zone

Primero una idea de lo que queremos hacer:

Dentro del formulario de login de XWiki, pondremos un enlace a una url dentro del propio XWiki que sea de la forma:
http://xwikiserver/.../viafirma.login

Esta URL será capturada dentro de la XWiki por un Filter que enviará al usuario automáticamente a Viafirma, que será el encargado de pedir el certificado digital al usuario y analizarlo (validarlo), tras esto enviará al usuario nuevamente a la XWiki (Viafirma coloca en la Session de esta petición el resultado de la validación del Certificado y será XWiki el encargado de tratar ese resultado) con una url con la forma:

http://xwikiserver/.../viafirmaAuthentication

El Request de esta URL será capturado por un Servlet que extiende al ViafirmaClientServlet, que nos proporciona el cliente de Viafirma, capturando de sesión el UsuarioGenericoViafirma que se ha obtenido. Este usuario aún no es un “usuario XWiki”. Este mismo Servlet se encargará de capturar la dirección a la que el usuario inicialmente quería acceder en XWiki y lo redirigirá allí de nuevo, siempre y cuando los resultados de Viafirma hayan sido válidos.

Por otro lado, extenderemos la clase XWikiAuthServiceImpl que implementa el servicio básico de autenticación de XWiki, introduciendo la posibilidad de realizar el Login en XWiki a partir de un UsuarioGenericoViafirma que tenemos en Sesión, para esto usaremos el API nativo de XWiki.

Por simplicidad para este ejemplo he adoptado la siguiente política de logado: dada una persona con NIF 12345678Z, su “Usuario XWiki” correspondiente será XWiki.12345678Z, es decir, debe existir un usuario dado de alta en XWiki cuyo Login coincida con el DNI de la persona. Cuando tengamos un UsuarioGenericoViafirma, consultamos su NIF y le preguntamos la XWiki a través de su API si existe usuario con ese Login. ¿Podría hacerse de forma más elaborada? Por supuesto, en vez de buscar un usuario con Login igual al Nif, podríamos haber definido una propiedad nueva para los Usuarios XWiki y para usarlo con este propósito, cuando lo hagáis no dudéis en poner vuestros comentarios al final de este post.

La secuencia de llamadas entre todos estos componentes lo podemos ver aquí:

Vamos a ir explicando paso a paso cómo hacer todo esto:
Paso 1.- Modificación del formulario de Login

Debemos editar el fichero templates/login.vm e introduciremos la redirección al servlet. Os propongo dos opciones, un enlace dentro de formulario ya existente y un formulario nuevo (para nuestro ejemplo funcionarán los dos):

...
<form>
...
#template("viafirmaLink.vm") <-Hiperenlace: opcion A
...
</form>
#template("viafirmaForm.vm") <- Formulario: opción B
...

Posteriormente copiaremos los ficheros viafirmaLink.vm y viafirmaForm.vm dentro del directorio templates.
Contenido de viafirmaLink.vm:

<div style="margin: 1em;">
 <a href="viafirma.login">ACCESO CON CERTIFICADO DIGITAL</a>
 <br/>
</div>

Contenido de viafirmaForm.vm:

<form id="loginFormViafirma" action="viafirma.login" method="post">
 <div>
 <fieldset>
 <legend>Certificado Digital</legend>
 <div><span><input type="submit" value="VIAFIRMA"/></span></div>
 </div>
</form>

Vemos que las dos opciones propuesta envian al usuario a la URL http://xwikiserver/…/viafirma.login .

Paso 2.- Implementación de un Filter, que será el encargado de capturar las peticiones a …/viafirma.login y enviar al usuario hacia Viafirma para que se autentique:

package org.viafirma.xwiki;
public class AuthenticationFilter implements Filter { ... }

Paso 3.- Implementación de un Servlet que recogerá de vuelta el resultado ofrecido por parte de Viafirma tras el análisis del certificado, capturando las peticiones a …/viafirmaAuthentication y coloque en sesión al usuario UsuarioGenericoViafirma:

package org.viafirma.xwiki;
public class AuthenticationServlet extends ViafirmaClientServlet implements Serializable { ... }

Paso 4.- Implementaremos un mecanismo usando otro Filter, para que Viafirma use una CSS definida por nosotros mismos. Viafirma “pide” por defecto una CSS llamada viafirmaStyle.css. En este ejemplo hemos optado por que XWiki sirva el CSS que usará Viafirma, aunque quizás lo más conveniente sea colocar este CSS en un servidor externo, por ejemplo un Apache, pero de todos modos vamos a hacerdo a modo de ejemplo. Bastaría con colocar una regla en Apache (por ejemplo) para que las peticiones al archivo viafirmaStyle.css no pasen a la XWiki, esto os lo dejo a vosotros.

Paso5.- Extenderemos el Servicio de Autenticación de XWiki, que sustituirá a la que tiene por defecto esta plataforma:

package org.viafirma.xwiki;
public class ViafirmaAuthImpl extends XWikiAuthServiceImpl implements  Serializable { ... }

Posteriormente, deberemos modificar el fichero xwiki.cfg de XWiki añadiendo o modificando:

xwiki.authentication.authclass=org.viafirma.xwiki.ViafirmaAuthImpl

Paso 6.- Configuraremos el web.xml de XWiki para dar de alta estos Filters y Servlets que hemos creado, adaptando los valores de los parámetros a nuestro entorno (url de Viafirma y ruta al css):

...
 <filter>
 <filter-name>ViafirmaLoginFilter</filter-name>
 <filter-class>org.viafirma.xwiki.AuthenticationFilter</filter-class>
 <init-param>
 <param-name>VIAFIRMA_URL</param-name>
 <param-value>http://viafirma.viavansi.com/viafirma</param-value>
 </init-param>
 <init-param>
 <param-name>VIAFIRMA_WS</param-name>
 <param-value>http://viafirma.viavansi.com/viafirma</param-value>
 </init-param>
 </filter>
 <filter>
 <filter-name>ViafirmaStyleFilter</filter-name>
 <filter-class>org.viafirma.xwiki.ViafirmaStyleFilter</filter-class>
 <init-param>
 <param-name>PATH_CSS</param-name>
 <param-value>D:/xwiki/skins/colibri/colibri.css</param-value>
 </init-param>
 </filter>

 <filter-mapping>
 <filter-name>ViafirmaLoginFilter</filter-name>
 <url-pattern>*.login</url-pattern>
 </filter-mapping>
 <filter-mapping>
 <filter-name>ViafirmaStyleFilter</filter-name>
 <url-pattern>*.css</url-pattern>
 </filter-mapping>
 ...
 <!-- Servlet de Autenticación de Viafirma-->
 <servlet>
 <servlet-name>viafirmaAuthentication</servlet-name>
 <servlet-class>org.viafirma.xwiki.AuthenticationServlet</servlet-class>
 </servlet>
 <servlet-mapping>
 <servlet-name>viafirmaAuthentication</servlet-name>
 <url-pattern>/viafirmaAuthentication/*</url-pattern>
 </servlet-mapping>

Finalmente tendremos esto:

Teneis el proyecto mavenizado y todos los fuentes usados en este ejemplo aquí:

Para integrar este ejemplo en XWiki, sólo es necesario:

1. Empaquetar las clases generadas en un .jar y copiarlo en el WEB-INF/lib de XWiki, también deberá copiar en esa carpeta todas las librerías dependientes.
2. Realizar las modificaciones anteriormente indicadas en el formulario de Login.
3. Copiar los archivos .vm a la ruta indicada anteriormente.
4. Modificar y configurar el web.xml de XWiki.

Aquí os dejo unas capturas de pantalla para demostraros que todo esto funciona correctamente

Formulario para logarnos:

Finalmente, vemos que XWiki nos ha logado correctamente:

Selección del Certificado Digital en Viafirma, vereis que tiene el CSS que queremos (obviamente ese CSS se puede mejorar) :

Finalmente veremos que ya estamos logados en XWiki (enhorabuena !!) :

Esto nos da por pensar en próximos capítulos: ¿publicación de contenidos firmados digitalmente? Quién sabe…

Un Saludo.

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.

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

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)

En VIAVANSI estamos de enhorabuena, ayer lunes 16/03/2009 entró en producción la Aplicación de gestión de las Acciones formativas de las empresas, de la Fundación Tripartita para la Formación en el Empleo (antiguo FORCEM). En esta institución han escogido Viafirma para introducir las funcionalidades de autenticación con certificados digitales con multitud de CA’s como DNI electrónico, FNMT, IZENPE, Camerfirma, ANCERT, Firma Profesional, etc.

(más…)

Debido al gran interés que esta generando Viafirma, nuestra plataforma de Autenticación y Firma Digital en su versión comercial, hemos creado viafirma.com, en la que se recoge toda la información relacionada con las versiones comerciales de la plataforma ( Versión Standard y Advanced).

 ¿Por qué una versión comercial de Viafirma?

En la mayoría de los casos, nuestros clientes desean utilizar Viafirma sobre aplicaciones que no son compatibles con GPL; además, nos exigen soporte técnico, mantenimiento, plazos para nuevos desarrollos, tiempos de respuesta, una documentación completa, y en resumen, unas garantías que no ofrece la versión GPL. Por este motivo y para poder financiar los nuevos desarrollos a los que nos estamos enfrentando, hemos creado el portal  viafirma.com.

¿Implica esto un cambio de filosofía de la versión Software Libre?

No. Tenemos tanto que agradecer a la comunidad que nuestra intención sigue siendo apostar por una plataforma libre . De hecho acabamos de liberar como GPL la nueva versión de Viafirma 1.3.2, si lo desean pueden consultar la lista completa de nuevas funcionalidades en viafirma.org.

Ya tenemos nueva versión de Viafirma (Nuestra plataforma de Firma y Autenticación Digital),  la lista completa de cambios es:

• Migración del stack WebSerice utilizado, antes Xfire, ahora JAX-WS 2.1.
• Nuevo método para el envío de emails firmados digitalmente.
• Cache de CRLs para minimizar el número de accesos a CRLs externas.
• Soporte de firma en servidor (indicando el alias y el password) y custodia de documentos firmados offline.
• Actualizada la versión de la librería OpenId para el soporte completo de OpenId 1.1 y OpenId 2.0 (draft)
• Mejorada la documentación de instalación y creada aplicación pre-empaquetada .war .
• Añadido digito de control al identificador de firma.
• Validación y recuperación de documentos custodiados mediante el identificador del documento.
• Uso de friend-url para el acceso a documentos custodiados, ej:http://viafirma.viavansi.com/viafirma/v/Y1MW-9LE3-JE81-2087-8160-3774.
• Mejorado el renderizado del QR-CODE, añadida información hash del documento y mejoradas en el formato de la etiqueta.
• Mejorado el renderizado del justificante pdf, para formatos no A4.
• Parametro para control de acceso al Servicio Web , ALLOWED=”ip,ip2″ indica que ips tienen permiso para acceder al servicio web.
• Soporte de certificados almacenados en “Acceso a Llaves” de Mac OSX (Con esto ya tenemos soporte completo de Mac OS X).
• Solución de bugs en el css para IE6 e IE7.
• Solución de bug en el envio de mimetype al navegador.
• Añadido método al api cliente, que permite retornar una imagen png con el código de barras y QR code del documento custodiado.
• Se ha añadido a la demo de la plataforma la posibilidad de firmar un documento de ejemplo, sin necesidad de subir uno ya existente.
• Mejorado el parseador de Oids, para extraer correctamente los datos del certificado.