Buscar en xnoccio
Archivos del sitio
Java / JEE : Firma digital y autenticación con Viafirma (I)
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/repoSi 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
Próximamente: Java / JEE : Firma digital XADES y facturae con Viafirma (II)
Hudson. Parte 2. Crea tus propios plugins
Una de las ventajas de Hudson es la posibilidad que nos ofrece de ampliar su funcionalidad mediante su sistema de plugins. De esta forma, podemos realizar acciones sobre los builds, tales como generación de informes, controladores, acciones sobre el código fuente, etc. En Internet podemos encontrar algunas páginas de donde descargar plugins para Hudson, como por ejemplo http://hudson.gotdns.com/wiki/display/HUDSON/Plugins.
Aún disponiendo de una cantidad considerable de plugins en la red que cubran la mayoría de las necesidades, nos podemos encontrar en la situación de tener que crear uno propio. Si te has planteado desarrollar uno te habrás dado cuenta de que la documentación en Internet sobre cómo crear un plugin es muy escasa, estando el grueso de la información en sólo dos páginas: http://hudson.gotdns.com/wiki/display/HUDSON/Plugin+tutorial y http://javaadventure.blogspot.com/2008/01/writing-hudson-plug-in-part-1.html.
Pues bien, en Viavansi surgió la necesidad de crear un plugin para Hudson que subiera el código fuente de un proyecto a un repositorio de Subversion, de forma que se automatizara esta tarea cada vez que Hudson hiciera un build.
El plugin constará de una parte de configuración en donde el usuario encargado de cada proyecto introducirá la url del repositorio de Subversion donde desea subir el código, los parámetros relativos al repositorio (nombre de usuario y password) así como dos entradas para ficheros que no se quieren subir o ficheros que no se quieren sobreescribir en el destino. Además dispondrá de una opción para habilitar o deshabilitar el plugin en todos los proyectos de forma global.
Creación de la estructura del plugin
Lo primero que vamos a tener que usar para crear el plugin es la herramienta Maven, la cual nos creará la estructura de paquetes, además de algunos ficheros de ejemplos. Esto era de esperar, pues Hudson internamente usa Maven para la creación de los builds de los proyectos.
Empezamos situandonos en una consola sobre nuestro directorio de proyectos y tecleamos:
mvn hpi:create
Después de pedirnos algunos datos como el identificador del grupo y el nombre del plugin, Maven nos creará la siguiente estructura:
+ src
+ main
+ java
+ groupid.name
+- PluginNamePublisher.java
+- PluginImpl.java
+ resources
+ groupid.name.project
+- config.jelly
+- global.jelly
+- index.jelly
+ webapp
+- help-globalConfig.html
+- help-projectConfig.html
Por defecto, se crean unos ficheros de ejemplo (el archiconocido HelloWorld) que podemos usar para ver cómo está implementado un plugin sencillo.
Si queremos tener soporte en nuestro IDE para la implementación del plugin deberemos, en el caso de Eclipse, tendremos que introducir lo siguiente:
mvn -DdownloadSources=true eclipse:eclipse
Si tenemos otros entornos como Netbeans o IntelliJ, existen plugins específicos de Maven para estos IDEs.
Bien, acabamos de crear la estructura de nuestro primer plugin, nos falta decirle a Hudson qué tipo de plugin hemos desarrollado, agregar la lógica y crear los campos visuales para que se añadan a las páginas de configuración de los proyectos.
Creando el plugin
Uno de los aspectos más importantes en la creación de un plugin para Hudson consiste en determinar el tipo de proyecto para el que va a ser utilizado. En nuestro caso utilizamos proyectos de tipo Maven, por lo cual necesitamos publicar el plugin en Hudson a través de un Publisher; en caso contrario (para proyectos de tipo Ant, por ejemplo) necesitaríamos publicarlo usando un Builder. Otra de las características de usar un Publisher frente a un Builder consiste en que la acción se ejecuta cuando un proyecto ha terminado de hacer el build.
Para publicar el plugin mediante un Publisher basta con tocar la clase PlugImp quedando de la siguiente forma:
public class PluginImpl extends Plugin {
public void start() throws Exception {
//Publicamos el descriptor del plugin
Publisher.PUBLISHERS.add(SVNCopyPublisher.DESCRIPTOR);
}
}
En este código podemos ver como se ha modificado la clase inicialmente creada por Maven, añadiendo la línea donde le decimos a Hudson que registre nuestro plugin. Debido a que la funcionalidad que queremos desarrollar consiste en copiar el código fuente de un proyecto a un repositorio de Subversion, el nombre de nuestro plugin será SVNCopyPlugin (original, verdad?), creando así la clase SVNCopyPublisher que será la que contenga el descriptor y la lógica de negocio.
Los elementos más importantes de la clase SVNCopyPublisher son:
- Atributos necesarios para la ejecución de la lógica del plugin. En nuestro caso, url del repositorio, nombre de usuario, contraseña y listas con los ficheros que no queremos subir o que no queremos sobreescribir. Cada atributo deberá tener un método público get y set.
-
Un constructor público en el que pasaremos los valores de los campos rellenados por el usuario en la configuración del plugin e inicializaremos los atributos definidos en el punto anterior. Además, este constructor deberá estar anotado con @DataBoundConstructor.
-
Un método perform en donde se colocará la lógica de nuestro plugin.
-
Un atributo estático y final llamado DESCRIPTOR que será instancia de una clase interna de nombre DescriptorImpl.
A su vez, la clase DescriptorImpl contendrá la configuración global del plugin. En el caso de SVNCopyPlugin hemos usado en la configuración local un checkbox con el cual activaremos el uso del plugin y sólo realizará la copia cuando esté activado.
Además esta clase debe contener:
-
Los atributos propios de la configuración global del plugin, con sus gets y sets.
-
Un constructor protected sin parámetros.
-
El método configure que hará persistente la configuración global.
-
Un método newInstance que devolverá una instancia de nuestra clase Publisher con los valores introducidos por el usuario.
Hasta aquí ha sido todo teoría, veamos ahora como queda la clase SVNCopyPublisher y su clase interna DescriptorImpl:
public class SVNCopyPublisher extends Publisher {
private Boolean enable;
private final String urlTarget, nameTarget, passTarget, filesTargetException, filesSourceException;
@DataBoundConstructor
public SVNCopyPublisher(String urlTarget, String nameTarget, String passTarget, String filesSourceException, String filesTargetException) {
this.urlTarget = urlTarget;
this.nameTarget = nameTarget;
this.passTarget = passTarget;
this.filesTargetException = filesTargetException;
this.filesSourceException = filesSourceException;
}
…
//GETTERS y SETTERS de los atributos
…
public boolean needsToRunAfterFinalized() {
return true;
}
/*
* Contiene la lógica del plugin, que se ejecutará cuando termine el build de Hudson
*/
@Override
public boolean perform(AbstractBuild<?, ?> build, Launcher launcher, BuildListener listener) throws InterruptedException, IOException {
if(enable && build.getResult().equals(Result.SUCCESS)){
//Aquí debe ir la lógica de negocio del plugin
…
}
return true;
}
public Descriptor<Publisher> getDescriptor() {
return DESCRIPTOR;
}
public Action getProjectAction(AbstractProject< ?, ?> project) {
return null;
}
/**
* Descriptor should be singleton.
*/
public static final DescriptorImpl DESCRIPTOR = new DescriptorImpl();
/**
* Descriptor for {@link SVNCopyPublisher}. Used as a singleton.
* The class is marked as public so that it can be accessed from views.
*/
public static final class DescriptorImpl extends Descriptor<Publisher> {
/**
* If you don’t want fields to be persisted, use transient
*/
private boolean enable;
protected DescriptorImpl() {
super(SVNCopyPublisher.class);
load();
}
/**
* This human readable name is used in the configuration screen.
*/
public String getDisplayName() {
return “SVNCopy Plugin Project Configuration”;
}
/**
* Get the fields from the global configuration form and persist them.
*/
public boolean configure(StaplerRequest req, JSONObject o ) throws FormException {
enable = o.getBoolean(“enable”);
save();
return super.configure(req,o);
}
/**
* Creates a new instance of {@link SVNCopyPublisher} from a submitted form.
*/
@Override
public SVNCopyPublisher newInstance(StaplerRequest req, JSONObject formData) throws FormException {
SVNCopyPublisher pub = req.bindJSON(SVNCopyPublisher.class, formData);
pub.setEnable(enable);
return pub;
}
public boolean isEnable(){
return enable;
}
}
}
Del código de arriba podemos destacar el método perform, que es el encargado de llamar a la lógica del plugin, recibiendo como parámetros una instancia de AbstractBuild (usado para lanzar el plugin si el build ha terminado satisfactoriamente), una de Launcher que contiene datos de la máquina que realiza el build y otra de Listener, que entre otras cosas contiene el logger con el cual podemos imprimir en la consola web de Hudson nuestra salida del plugin. Otros métodos importantes son configure y newInstance que reciben como parámetros la petición del formulario de configuración y los datos introducidos por el usuario en forma de JSON. El parámetro StaplerRequest forma parte del framework Stapler utilizado por Hudson para la aplicación web y es útil si queremos obtener datos de la petición usando getParameter.
Generando los formularios y uniéndolos al código del plugin
Para terminar con el desarrollo de nuestro plugin nos falta crear los formularios de entrada en la parte de configuración global de Hudson, así como en la configuración particular de cada proyecto. Maven nos crea por defecto los ficheros global.jelly y config.jelly, además de unos htmls de ayuda. Estos ficheros siguen un esquema XML basandose en un framework ligero llamado Jelly http://commons.apache.org/jelly/.
Para comenzar, tenemos que incluir en la configuración global de Hudson el checkbox que habilitará de forma general el uso del plugin para todos los builds que se hagan (además se dispone de otro checkbox que habilita el plugin para cada proyecto). Dentro de la carpeta resources se encontrarán como mínimo tres ficheros .jelly: index, global y config. El primer fichero contiene una descripción del plugin y en los otros dos se deberá colocar los elementos htmls para la configuración global y específica del mismo.
En el fichero global.jelly queremos colocar el checkbox que hará que se active el plugin para todos los proyectos. Para ellos basta con colocar las siguientes lineas:
<j:jelly xmlns:j=”jelly:core” xmlns:st=”jelly:stapler” xmlns:d=”jelly:define” xmlns:l=”/lib/layout” xmlns:t=”/lib/hudson” xmlns:f=”/lib/form”>
<f:section title=”SVNCopyPlugin Global Configuration”>
<f:entry title=”Enable”
description=”Check if you want to perform a copy of your project from your repository to another one”>
<f:checkbox name=”enable” checked=”${descriptor.isEnable()}” />
</f:entry>
</f:section>
</j:jelly>
Como se puede apreciar el código es bastante autoexplicativo. Se usan unos tags propios de Jelly para añadir el checkbox a la configuración de Hudson (Manage Hudson / Configure System). El valor del checkbox estará bindeado al atributo enable ya visto en el descriptor.
Por otra parte el fichero config.jelly contendrá la configuración específica del plugin para cada proyecto. Su contenido será el siguiente:
<j:jelly xmlns:j=”jelly:core” xmlns:st=”jelly:stapler” xmlns:d=”jelly:define” xmlns:l=”/lib/layout” xmlns:t=”/lib/hudson” xmlns:f=”/lib/form”>
<!–
Cajas de texto para introducir las url de los dos repositorios, los nombres y los passwords
–>
<f:entry title=”URL del repositorio destino”>
<f:textbox field=”urlTarget” value=”${descriptor.urlTarget}”/>
</f:entry>
<f:entry title=”Nombre de usuario del repositorio destino”>
<f:textbox field=”nameTarget” value=”${descriptor.nameTarget}”/>
</f:entry>
<f:entry title=”Password del repositorio destino”>
<f:password field=”passTarget” value=”${descriptor.passTarget}”/>
</f:entry>
<f:entry title=”Ficheros y carpetas que no se desean sobreescribir en el destino”>
<f:textbox field=”filesTargetException” value=”${descriptor.filesTargetException}”/>
</f:entry>
<f:entry title=”Ficheros y carpetas que no se desean subir al destino”>
<f:textbox field=”filesSourceException” value=”${descriptor.filesSourceException}”/>
</f:entry>
</j:jelly>
Gracias a este fichero se incluirá en la configuración del proyecto las cajas de texto para que cada usuario introduzca sus datos sobre el repositorio. Cada elemento f:textbox leerá/escribirá su valor en un atributo del descriptor.
Ejecución y debug
Con todo esto ya hemos terminado de programar el plugin, ahora sólo queda ejecutarlo y ver que todo va como deseamos. Para ello usaremos el comando mvn hpi:run desde la carpeta del plugin, el cual nos montará un Hudson en nuestra máquina y con el que podremos trastear antes de instalarlo en el Hudson de la empresa.
También es interesante la opción de debuguear para seguir la traza y ver qué valores van tomando cada uno de los elementos que intervienen en la ejecución del plugin. Para tener la posibilidad de debuguear antes de llamar a mvn hpi:run tendremos que setear las variables de entorno con los comandos:
export MAVEN_OPTS=”-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000,suspend=n”
si usamos Unix o
set MAVEN_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000,suspend=n
si usamos Windows.
Empaquetando y exportando el plugin
Para finalizar sólo queda crear el fichero .hpi para importarlo desde el Hudson instalado en uno de los servidores de la empresa, algo tan sencillo como ejecutar mvn hpi:package y coger el fichero con esta extensión creado en la carpeta target.
Con esto ya tienes para empezar a customizar tu Hudson añadiendole la funcionalidad que necesitas y no te la dan otros plugins. Ya se sabe, si no está: hazlo tu mismo.
Próximamente…
En breve pondremos una entrada explicando cómo sacarle más partido a los plugin de Hudson, añadiendo interacción con el usuario, generación de informes del plugin por cada build, etc.
VIAVANSI abre su canal Twitter
Con el título de este post poco más hay que explicar 
En la URL http://twitter.com/viavansi tenéis ya disponible el Twitter corporativo de VIAVANSI. A través de los tweets pondremos a disposición de todos noticias informales del día a día de nuestra empresa, el sector TIC, etc.
Invitamos a todos nuestros lectores a ser followers!
Namasté.
Humor: GUÍA DE INGLÉS ZUBURBIAL (II)
Continuamos con la guía iniciada en Guía de Ingles Zuburbial (I):
LIGANDO
En los zuburbios, es imprescindible relacionarse. Para caer bien a las chicas, tienes que alagarlas. Y ¿qué mejor forma de alagar que los típicos piropos de tu tierra? Son universales y calarán en cualquier país. Algún ejemplo:
- Pretty you are, doughter! (¡Guapa ere… hija!)
- Girl, go here what you hear (Niña, ven pacá que te vas a enterá)
- I’m more hot that sanjacobos’s chease (Estoy más caliente que er queso de los sanjacobo)
- Cuando la tengas en el bote, podrás cantar victoria: “This night, you don’t scape with wings” (Esta noche no te escapas ni con alas).
VIAVANSI EN INGLÉ
Por último, es importante exportar siempre las peculiaridades de tu entorno de trabajo. Por lo tanto, en los zuburbios ingleses utiliza tus expresiones de siempre pero de forma que se te entienda:
- In zero-comma-two (En cero coma dos). Hacer algo muy rápido.
- To be a big border (Ser un filón). Una ganga, vamos.
- To be strange (Ser arcano), o Find a stranged (encontrarse una arcanidad)
- King Kong’s shit (Mojón de King Kong). Algo hecho rematadamente mal.
- To make you the bed (Hacerte la cama). No dejes nunca que te la hagan. Es malo.
- You are a person without arm! (¡Eres un muñón!). Para los malos programadores.
- Withfather (Compadre). Para los compañeros del alma.
Espero que sea suficiente para que tu estancia en la tierra de Ckeck’s Pierre sea lo menos traumática posible y te puedas integrar con lo más bajo del país.
Metadatos
Siguiendo con el tutorial que queremos realizar acerca de la web semántica, nos parece que uno de los puntos principales va a ser la definición de los conceptos alrededor de los cuales gira la Web Semántica, conceptos que si bien no son nuevos (los hay incluso heredados de la Filosofía), han visto su significado adaptado en esta nueva tecnología. A lo largo de estas entradas voy a intentar simplificar todo lo que pueda y a hacer la asunción de que el lector desconoce por completo el tema, así que disculpadme si pensáis que estoy tratando algo básico. Para eso están los comentarios, para que opinéis
El concepto más importante, y a la vez probablemente el más conocido, es el de metadato (metadata en inglés). Los metadatos se definen como “datos acerca de otros datos”, lo cual por sí mismo puede resultar una definición pobre. Sin embargo, un ejemplo lo dejará mucho más claro: imaginemos una canción en el ordenador (una canción en formato ogg vorbis y descargada desde Jamendo, por supuesto 
). Esta canción es analizada por nuestro reproductor de música preferido que (normalmente) es capaz de mostrar diversa información acerca de ella. Como mínimo, los nombres de la canción, cantante y álbum. Estos tres campos son información (datos) acerca de la canción (otros datos) .
Si os dais cuenta, el mundo está plagado de metadatos: la mayoría de las cámaras digitales “firma” las fotografías con, entre otras cosas, la fecha de toma de la instantánea; los ficheros de un sistema operativo derivado de UNIX (como Linux y OS X) tienen metadatos que definen qué usuarios tienen (o no) acceso a ellos; y en aplicaciones web como Flickr las fotografías tienen etiquetas asociadas para facilitar su clasificación.
¿Y cuál es la relación de los metadatos con la web semántica? Son el elemento básico para formarla, pues recordemos que la web semántica pretende hacer posible que los ordenadores entiendan los contenidos de la web. El método exacto para lograrlo lo veremos en posteriores entregas, pero de momento creedme cuando escribo que los metadatos van a ser vitales en el proceso
Viafirma 2.2: Soporte de integración con @Firma
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.
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.
Samba en Mac, publicidad subliminal
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
La web semántica
Ayer comenzamos con lo que pretendemos sea una colección de artículos acerca de la web semántica, que iremos desarrollando a lo largo de las siguientes semanas. En la entrega de hoy, daremos una pequeña introducción acerca del tema. Ya que nosotros también estamos aprendiendo en este momento, espero que nos perdonéis y corrijáis posibles errores
En la actualidad, la web es una colección de datos inmensa, que permite a una persona acceder a una gran cantidad de información y operar sobre ella. Sin embargo, lo que es una virtud se puede entender también como uno de sus grandes defectos, debido a que existe tanta información que cada día resulta más complicado procesarla y hacer consultas sobre ella. Además, la heterogeneidad en las fuentes de información dificulta en gran medida la interoperabilidad entre sistemas.
La web semántica es una evolución de la actual tecnología, pensada para proveer de contenido semántico a la web actual. Gracias a este contenido semántico se posibilita que no sólo una persona pueda entender la información que presenta una página web, sino que se habilita a las máquinas a tal efecto. De esta manera, un buscador puede realizar una consulta de una forma más inteligente, procesando los resultados y descartando o seleccionando los que mejor se adaptan a los parámetros de la búsqueda.
En el fondo, la web semántica trata de proveer un cierto grado de inteligencia a la web actual. Tim Berners-Lee, el inventor del World Wide Web y uno de los principales valedores de la web semántica, se expresaba así en 1999:
I have a dream for the Web [in which computers] become capable of analyzing all the data on the Web – the content, links, and transactions between people and computers. A ‘Semantic Web’, which should make this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The ‘intelligent agents’ people have touted for ages will finally materialize.
Una traducción un poco libre
He tenido una visión para la Web [en la cual los ordenadores] serán capaces de analizar todos los datos de la Web – los contenidos, enlaces y operaciones entre las personas y las máquinas. Una ‘Web Semántica’, que debería hacer esto posible, todavía tiene que aparecer, pero cuando lo haga, las operaciones diarias de comercio, burocracia, y nuestras vidas serán manejadas por máquinas hablando con otras máquinas. Los ‘agentes inteligentes’ que la gente ha esperado por años finalmente se harán realidad.
Web Semántica: Cool URIs
Dentro del escenario de la web semántica, el estándar del Cool URIs se centra en definir el mecanismo de acceso a recursos basados en URIs, así como concretar el protocolo de negociación para el acceso a dichos recursos.
Este estándar, facilita la interoperabilidad del contenido web en el contexto de la web semántica, indicando como publicar la información sobre los recursos de manera que tanto máquinas como humanos puedan acceder a ella de una forma sencilla.
Para conseguir esto, el estándar define un conjunto de pautas básicas a seguir a la hora de publicar URIs, de este conjunto de pautas, las más interesantes son:
- Las URIs deben ser semánticas, de forma que teniendo sólo las URIs tanto máquinas como personas puedan obtener una descripción del tipo de recurso identificado.
- A una misma URI, las máquinas deben obtener RDF y las personas una visión legible en HTML. De forma más general se recomienda adaptar la respuesta al cliente que solicita el recurso, de forma que los humanos obtengan contenido inteligible por ellos y las máquinas obtengan algun tipo de recurso fácilmente procesable.
- Las URIs no deben ser ambiguas. Hay que distinguir entre documentos web e identificadores de recursos. No se deben utilizar URIs a documentos para identificar recursos reales. Se recomienda usar un mecanismo de resolución que en función de un identificador de recurso (URI) redirija al contenido RDF o al contenido HTML en función del tipo de cliente que solicita el recurso.
- Uso de Hash URIs o 303 URIs para el acceso a recursos parciales (zonas de documentos, o recurso no reales)
- Hash URIs: Utilizando el símbolo “#” para referenciar fragmentos o partes especiales de una URI. Esta es la opción preferída.
- Uso del estado HTTP 303 para la redirección del usuario al recurso o fragmento indicado.
- Las URIs deben ser simples y fáciles de recordar.
- Las URIs deben ser estables y pensadas para continuar durante años. Por este motivo no deben aparecer extensiones relacionadas con la tecnología (.jsp, .asp, .php, etc… ).