Xnoccio

Nuestros compañeros de OpenCms han sacado el nuevo sitio web de la Consejería de Turismo, Comercio y Deporte de la Junta de Andalucía. Ha sido un duro proyecto trabajado en equipo entre el personal de VIAVANSI (enhorabuena Tino, Carlos, Antonio, Cristina, Javi, Álvaro, Juan, Enrique, Fernando, Silvia, Diego…) y el del cliente, que ha trabajado como un miembro más del equipo. Gracias por ello a Joaquín Vázquez, Mercedes Soto, Manolo Martín Matas, Alberto Díaz, Pepe Campos, etc. etc.).

El portal la verdad es que mejora mucho al anterior, y dentro de las férreos marcos que rodean a los sitios web de las instituciones públicas, introduce algunos conceptos que, si bien son comunes en otro tipo de portales, resultan innovadores en un sitio oficial; por ejemplo, la zona más expuesta al público y central la ocupan una serie de vídeos multimedia servidos vía streaming.

El portal ha sido desarrollado bajo tecnología OpenCms 7.0.4 / Oracle.

Le deseamos una excelente andadura al nuevo portal.

Dice la competencia que después de la fusión entre Sun y Oracle tal vez el nuevo logo de Java EE vaya a ser como el que sigue:

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é.

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.

Acaba de salir publicada la nueva versión 2.1.0 de Maven. Se pueden consultar las modificaciones incluidas en las Release Notes de la versión.

Está calentito calentito; esta misma semana empezamos a trabajar con esta versión, e iremos comentando las novedades que vemos. De momento os puedo anticipar que por fin las contraseñas almacenadas en el settings.xml están ofuscadas :-)

Como muchos de nuestros lectores sabrán, el día 19/03/2009 a las 18h se vio publicada la nueva versión 8 del navegador de Microsoft, Internet Explorer.

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

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

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.

(more…)

Reciéntemente he estado revisando la arquitectura técnica de un proyecto Java EE que estaba teniendo serios problemas de escalabilidad. En Desarrollo todo iba como un tiro, pero con un número importante pero no escandaloso de registros (apenas 100.000) nos encontrábamos con tiempos de respuesta de algunas de las operaciones online que se podían ir a los 5 minutos. Obviamente esos tiempos no son admisibles para una operación web, por lo que urgía detectar fuentes de problemas y optimizar los procesos.

Realmente no había ninguna parte del código culpable al 100%, sino que la funcionalidad implementada, excesivamente flexible para el usuario,  le permitía a éste realizar búsquedas y operaciones que finalmente implicaban una sucesión de consultas, filtrados, operaciones de unión/intersección de listas enormes, persistencia…

Para muchas de las listas que se manejaban, se podía garantizar su invariabilidad en un tiempo elevado. Datos, por ejemplo, relativos a provincias. Por ello daba la sensación de que implementar una caché de estas listas, y sobre todo de los resultados finales después de las mencionadas operaciones de unión/intersección, etc., podría ser oportuno. Es cierto que Hibernate permite caché de resultados (y de hecho utiliza Ehcache), pero en este caso hablamos de resultados post-procesados, por lo que no sería suficiente.

Cachear objetos en una aplicación Java EE es algo básicamente trivial: siempre disponemos de la opción de ubicar el objeto en contexto de aplicación (ServletContext) y recuperarlo cuando queramos. Sin embargo esta aproximación no deja de ser algo “de juguete”. Decidimos utilizar Ehcache en primer lugar porque sabíamos que Hibernate sacaba un buen provecho de él, pero sobre todo porque, con un desarrollo extremadamente sencillo, obtenemos importantes ventajas funcionales como:

• Gestión de caducidad del contenido. Pasado un tiempo determinado, la caché elimina el objeto cacheado y comienza a devolver NULL a las peticiones posteriores. Nos elimina la responsabilidad de persistir el tiempo de vida de un objeto cacheado.
• Configuración del máximo número de objetos a cachear en memoria. Podemos dimensionar la cantidad de objetos que deseamos cachear en memoria. Ehcache se encarga de serializar a disco todo lo que le sobra, y recuperarlo cuando sea necesario. Ni que decir tiene que todos los objetos a cachear deberán ser serializables.
• Posibilidad de despliegue en cluster.
• Eliminación de la caché durante el shutdown del servidor de aplicaciones.
• ¡No reinventar la rueda!

Al final desarrollamos una sencilla clase tipo Manager, implementando el patrón Singleton, que interactúa con Ehcache. Y en determinadas zonas de la aplicación, invocar a la cache para recuperar los objetos que anteriormente se generaban online.

Paso a poner el código, que al final sin chicha esto se queda en nada :-) Eso sí, me gustaría recalcar que el proceso de 5 minutos al final, con un poco de cariño, ha pasado a responder en menos de 10 segundos. Una ganancia de un 3000%…

/*
* File: CacheUtil.java
*
* Created on march 2009
*
*
* Copyright 2006-2029 Javier Echeverría Usúa (javieu at gmail.com)
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*     http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
package com.viavansi.framework.core.cache;

import net.sf.ehcache.Cache;
import net.sf.ehcache.CacheManager;
import net.sf.ehcache.Element;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import com.viavansi.framework.core.persistencia.servicios.excepciones.ExcepcionServicio;


/**
* @author Javier Echeverria Usua (javieu at gmail.com)
* @author Felix Garcia Borrego (borrego at gmail.com)
* @author Alexis Castilla Armero (pencerval at gmail.com)
*/
public class CacheUtil {

public Object getCachedObject(String key) throws Exception{

if(minutosVidaDefault == 0)
minutosVidaDefault = MINUTOS_DEFAULT;

return getCachedObject(key, minutosVidaDefault);
}

public void putCachedObject(String key, Object info) throws Exception{

if(minutosVidaDefault == 0)
minutosVidaDefault = MINUTOS_DEFAULT;

putCachedObject(key, info, minutosVidaDefault);
}

public Object getCachedObject(String key, int minutosCache) throws Exception{

Cache cacheCustodia = getInstance(minutosCache);
Element element = cacheCustodia.get(key);
if(element != null){
return cacheCustodia.get(key).getValue();
}
else{
return null;
}
}

public void putCachedObject(String key, Object info, int minutosCache) throws Exception{

Cache cacheCustodia = getInstance(minutosCache);
cacheCustodia.put(new Element(key,info));
}

private Cache getInstance(int minutosCache) {
Cache cache = null;
//Todavía no existe
int timeTolife = minutosCache * 60;

CacheManager manager = CacheManager.getInstance();

String nombreCache = "viavansiCachedInfo" + minutosCache;

if (manager.cacheExists(nombreCache)) {
cache = manager.getCache(nombreCache);
} else {
// Configuramos el apagado en caso de Error de la JVM o parada inesperada.
System.setProperty("net.sf.ehcache.enableShutdownHook", "true");
manager.addCache(new Cache(nombreCache, 100, true, false, timeTolife, timeTolife));
cache = manager.getCache(nombreCache);
}

return cache;
}

public static void shutDown() {
CacheManager.getInstance().shutdown();
}

private int MINUTOS_DEFAULT = 60;

private static int minutosVidaDefault = 0;

protected CacheUtil(int minutosVida) {
minutosVidaDefault = minutosVida;
}

public static void init(int minutosVida) {
minutosVidaDefault = minutosVida;
}

/*
* Constructor y accesores
*/

// Patrón Singleton
private static CacheUtil singleton;

//Instancia de Commons Logging
private Log log = LogFactory.getFactory().getInstance(this.getClass().getName());

/**
* private constructor (solo una instancia).
* @return AmbitoBO
*/
protected CacheUtil() throws ExcepcionServicio {
super();
log.debug("Creando nueva instancia de CacheUtil");
}

/**
* Devuelve instancia activa de AmbitoBO.
* Típico método de implementación de patrón singleton
* @return AmbitoBO
* @throws ExcepcionServicio
*/
public static CacheUtil getCurrentInstance() throws ExcepcionServicio {
if (singleton == null) {
try {
singleton = new CacheUtil();
} catch (ExcepcionServicio e) {
throw e;
}
}
return singleton;
}

}

Un saludo a todos, y poned una caché en vuestros corazones :-P

Desde VIAVANSI, los redactores de Xnoccio os deseamos felices fiestas y que para el 2009 todo vaya bien o mejor. Gracias por vuestra fidelidad!

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.