Tags: java

Java 7 and Mac OS X applet problems

01 Feb 2013

Las últimas semanas están siendo convulsas para la ejecución de applets Java en navegadores web en entorno Mac, debido a las vulnerabilidades de varias versiones de la JRE 7 que se han publicado muy recientemente. Eso afecta a las plataformas de firma electrónica, que utilizan applets para la interacción con los almacenes de certificados locales, y la generación de firmas electrónicas.

Hace apenas unos días Apple ha bloqueado la ejecución de applets Java en su sistema operativo. Desde la actualización a Java 7, los usuarios de Chrome en sistemas operativos Mac actualizados ya no podían ejecutar applets, debido a que la JRE 7 sólo soporta navegadores de 64-bits (y Chrome mantiene arquitectura de 32). Pero ahora, muchos usuarios ven que en su navegador Safari les sale “módulo inactivo” o “módulo bloqueado” al intentar cargar un applet Java. Ello es debido a que la última release publicada de la JRE, la 7u11b21 (1.7.11.21) tiene según Apple vulnerabilidades, por lo que a bajo nivel exige una versión mínima 1.7.11.22 que todavía no existe.

La solución recomendable es esperar a que Oracle publique una nueva versión que sea aceptable para Apple, pero mientras tanto, existen soluciones temporales (algo complejas) para los usuarios que (como yo) no podemos esperar. Adjuntamos los pasos:

1.- Descargar e instalar la última versión de la JRE, la 7u11, y más concretamente, a día de hoy (1 de febrero de 2013), el build21. Puede ser que ya la tengáis instalada. Si no es así, al pulsar sobre “módulo inactivo” normalmente te llevará a la página de descarga de Oracle. En todo caso, la página es esta: http://www.java.com/es/download/mac_download.jsp?locale=es

2.- Asegurarnos de que Safari está actualizado, en su versión (a día de hoy) 6.0.2. En las Preferencias de Safari -> Seguridad, debemos tener seleccionado “Permitir Java”.

3.- Abrir Terminal, y escribir:

cd /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources

sudo vi XProtect.meta.plist (ahora vamos a editar el fichero con “vi”, quien no sepa o no le guste puede usar otro editor)

Debemos cambiar el valor 1.7.11.22 del fichero, para poner algo anterior. Yo he puesto 1.7.11.20 y todo me funciona correctamente:

<key>com.oracle.java.JavaAppletPlugin</key>
<dict>
<key>MinimumPlugInBundleVersion</key>
<string>1.7.11.22</string>
</dict>
NOTA para usuarios sin experiencia con el vi: Pulsamos I para ponernos en modo edición / inserción, vamos con las flechas hasta ese número, borramos y actualizamos, y luego pulsamos la tecla “esc” para salir del modo edición, y escribimos :wq! pulsando Enter a continuación. El fichero quedará guardado.
A continuación reiniciaremos Safari, y ya deberíamos tener Java, lo cual podemos comprobar entrando por ejemplo en esta URL:
http://www.java.com/en/download/testjava.jsp
Suerte!
UPDATE: Este post (en inglés) tiene información sobre este mismo tema.

SQLite Android: Hello SQLite!

05 Jul 2012

XAdES Plugtest Remote Event – XML Advanced Electronic Signatures

26 Mar 2012

As we announced in the PAdES post, ETSI Centre for Testing and Interoperability (CTI) is organizing a new Remote Plugtests Interop events for XAdES Signatures from 14th March to 28th March 2012.

This Remote event aims at conducting interoperability test cases on XAdES signatures (TS 101 903) and the XAdES Baseline Profile (TS 103 171).

This testing will provide full test coverage of the both specifications including testing signatures evolution, simulating real life situations.

This Plugtests event will enable participants to conduct 4 types of tests (Interoperability and Conformance):

  • Generation and cross-verification (Positive) tests
  • Only-verification (Negative) tests
  • Signature Upgrade tests
  • Conformance testing on XAdES Baseline Profile signatures

Plugtest XAdES

The purpose of these events is:

  • To enable participants to assess the level of interoperability of XAdES.
  • To identify additional issues that should be taken into account in future XAdES standardisation activities.
  • To improve the quality of XAdES specifications.
  • To ease the introduction of XAdES signatures, by providing the means to solve interoperability problems before widespread deployment..

You can get more information on plugtests portal for electronic signatures:  http://xades-portal.etsi.org/pub/index.shtml

As shown in our website, we can provide you a little description about de XAdES profiles differing in protection level offered. Each profile includes and extends the previous one:

  • XAdES, basic form just satisfying Directive legal requirements for advanced signature;
  • XAdES-T (timestamp), adding timestamp field to protect against repudiation;
  • XAdES-C (complete), adding references to verification data (certificates and revocation lists) to the signed documents to allow off-line verification and verification in future (but does not store the actual data);
  • XAdES-X (extended), adding timestamps on the references introduced by XAdES-C to protect against possible compromise of certificates in chain in future;
  • XAdES-X-L (extended long-term), adding actual certificates and revocation lists to the signed document to allow verification in future even if their original source is not available;
  • XAdES-A (archival), adding possibility for periodical timestamping (e.g. each year) of the archived document to prevent compromise caused by weakening signature during long-time storage period.

After this, you may be interested in free downloading one of our  development kits for Java, .NET or PHP from our website for developers to electronically sign on XAdES format.

JBoss Seam: render an external xhtml

02 Dic 2011

Plataforma de autenticación y firma digital sobre WebLogic

18 Jun 2010

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 .

XWiki: autenticando con Viafirma

18 May 2010

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í:

Descarga de fuentes 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.

Creando una aplicación web basada en OSGI con Eclipse

29 Abr 2010

A continuación se describen los pasos básicos a dar para crear una aplicación web  que en lugar de ser desplegada sobre la típica pila JEE, sea desplegada como un componente más dentro de un contenedor OSGi.

Jee tradicional vs OSGi

Para ello se mostrará como construir con Eclipse un bundle OSGi que haciendo uso de Jetty nos permita correr un servlet sobre Equinox.

  • Crear el proyecto base

En primer lugar, necesitaremos crear un plugin, indicando que es de tipo OSGI (implementación Equinox).

Crear un proyecto OSGi en Eclipse

  • Definición de las dependencias

Una vez que tengamos el proyecto creado, necesitaremos declarar las dependencias que necesitará nuestro módulo para poder funcionar como un servidor de aplicaciones. Las dependencias serán como mínimo:

  • javax.servlet
  • org.eclipse.equinox.http.jetty
  • org.eclipse.equinox.http.servlet
  • org.mortbay.jetty.server
  • org.eclipse.equinox.http.registry

Dependencias Eclipse OSGI Jetty

  • Construcción del servlet de ejemplo

Una vez tengamos declaradas los módulos dependientes, Eclipse se encarga de actualizar nuestro classpath y ya podremos programar nuestro primer servlet sin problemas de compilación.

/** * Osgi Example Servlet. * */
public class HolaMundoOsgiServlet extends HttpServlet{
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        System.out.println("Petición al Servlet OSGi");
 	resp.getWriter().append("Respuesta desde un Servlet Osgi");
 }}

Como podemos ver, se trata de un servlet normal, que debería ser mapeado en el web.xml y desplegado dentro de un contenedor de servlets.

  • Activación del servlet

A diferencia del modelo tradicional (definido por la especificación JEE), la activación del servlet no requiere ningún web.xml. En su lugar, definiremos (al igual que cualquier otro servicio OSGI) un nuevo punto de extensión de nuestra aplicación. Para ello accederemos a la pestaña “Extension” y añadiremos la extensión “org.eclipse.equinox.http.registry.servlet” a nuestro módulo. Con esto le hemos indicado a OSGi que nuestro módulo hace uso del contenedor de Servlet.

Añadir extension point para definir un servicio de tipo servlet

El siguiente paso será indicar la clase que implementa el nuevo servlet y el mapeo, para ello simplemente definiremos la propiedad alias y class del nuevo servlet asociado a la extensión creada previamente.

Configurar extensiones OSGi

Con esto ya tenemos nuestra primera aplicación web OSGi.

  • Probando nuestra aplicación.

Para probar la aplicación sólo es necesario ejecutar el proyecto (Run As…>OSGi Framework) y acceder con el navegador a http://localhost:8080/exampleSi todo ha funcionado correctamente, en consola deberemos ver algo como lo siguiente:

Persistence bundle started.
Activado módulo OSGi: Ejemplo OSGI!!
Activado Servlet OSGiProviderTracker: New service detected...
ProviderTracker: Added service org.eclipse.persistence.jpa.osgi.PersistenceProviderOSGi
Petición al Servlet OSGi

Aunque aquí sólo se muestra un ejemplo muy básico, OSGI ya nos ha demostrado ser de mucha utilidad en proyectos reales muy complejos.

Ampliando nuestra matriz de compatibilidad. Internet Explorer 9

19 Mar 2010

En Viafirma, continuando con el compromiso de soporte universal de navegadores, nos hemos adelantado al  lanzamiento del futuro  Internet Explorer 9 y hemos realizado una completa batería de pruebas.

Los resultados han sido muy buenos; las pruebas se realizaron sobre la versión preview de Internet Explorer 9 (1.9.7745.6019) usando un usuario sin permisos de administración sobre diferentes versiones de Windows 7. Gracias a estas pruebas podemos garantizar que, salvo cambios radicales en la versión final, los usuarios de Internet Explorer y Windows 7 podrán seguir firmando (con su DNIe o cualquier otro certificado) en el futuro.

Viafirma IE 9 Windows 7

Si quieres probarlo por ti mismo, te invitamos a que pruebes http://viafirma.viavansi.com/viafirma

Augi@s, sistema de gestión de residuos pionero en hablar E3L

22 Feb 2010

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

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

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

Por fin un estándar con el que entretejer nuestras aplicaciones.

25 Oct 2009

Recientemente se ha liberado la primera versión estable de Weld, la implementación de referencia de Web Beans (Java Context and Dependenty Injection JSR 299). Y aunque puede parecer una liberación cualquiera, en este caso estamos ante un evento realmente importante para el mundillo Java.

¿Por qué es importante esta liberación?

  • Por fin tenemos un estándar Java para la inyección, publicación, localización y búsqueda de componentes.
  • Promete una mejor orquestación entre componentes JEE, evitando los típicos problemas de interoperabilidad entre Beans Spring, componentes Seam, Wicket, JSF, EL, etc..)
  • Un remplazo estándar a las diferentes soluciones de inyección e IoC como Spring IoC, el prometedor Google Guice o el muy utilizado por nosotros Jboss Seam annotations.
  • Fin del infierno XML, definiendo un mecanismo estándar independiente de ficheros de definición XML, que junto con JSF 2.0, Servlet 3.0, JPA, Jax-ws, etc… simplifican el desarrollo JEE.

¿Consecuencias para la industria a medio plazo?

  • Es demasiado pronto para saberlo, pero…
    ¿Quizás el fin de la guerra de frameworks se inyección?…. (Google Guice vs Spring vs Jboss Seam). Consiguiendo un efecto similar al que consiguió JPA/JDO estandarizando el acceso a datos.
  • Por fin una especificación JEE con la que construir aplicaciones complejas de forma sencilla.
  • En un momento en el que muchas organizaciones están intentando estandarizar sus desarrollos, llegando incluso a restringir o imponer las tecnologías utilizadas, la preselección de implementaciones como Spring IoC o Seam carecerá de sentido. Siendo mucho más coherente la recomendación de estándares en lugar de restringir la evolución natural de la tecnología y la sana competición entre sus diferentes implementaciones.

¿Consecuencia para nosotros?

  • Ninguna…. Gracias a nuestra apuesta por Jboss Seam (desde hace ya unos años), esta especificación se encontraba ya en nuestra hoja de ruta antes incluso de que fuese un Draft, por lo que para nosotros será suficiente con una mínima adaptación al estándar.
  • La implementación es estable, la especificación muy bien pensada, y en las pruebas que hemos realizado con la beta, ha demostrado que consigue simplificar los desarrollos y hacer más comprensible el “oscuro arte de la inyección de componentes”.
  • En breve empezaremos a usarla en algún proyecto piloto (que pueda asumir el riesgo de I+D asociado), analizaremos en detalle los posibles problemas que puedan surgir, y si todo se comporta como promete a mediados de 2010 empezaremos a usar la nueva especificación en nuestros proyectos Java.

¿Defectos?

  • Llega demasiado tarde. Otros frameworks llevan, aunque de una forma mucho menos limpia,  ofreciendo algo similar desde hace ya mucho tiempo.
  • Todavía no conocemos sus defectos. Y eso es un gran problema ya que hasta que no conozcamos sus problemáticas asociadas no será seguro su uso en proyectos de envergadura.
  • Esperemos que en la huida del infierno de los ficheros de configuración XML, no nos metamos en  las tinieblas del uso de inyección e IoC para todo. Ya que una aplicación con una gran cantidad de componentes, comportamientos o atributos que dependen de la inyección hace muy complicada la comprensión de su funcionamiento.

En definitiva, todo indica que estamos antes una de las piezas clave del próximo JEE 6.