|
Guía para el
desarrollo de aplicaciones Web con el API de firma |
|
1. Entornos de ejecución de la API de
firma digital
2. Ejecución en estaciones de trabajo
2.1. Ejecución del API de firma mediante
Applets
2.1.1. Control de versiones mediante
extensiones de Java
2.1.2. Control de la versión de ejecución
de Java
2.2. Ejecución del API de firma mediante
Java Web Start
3. Ejecución en servidores de
aplicaciones J2EE
1. Entornos de ejecución de la API de firma digital
Debemos diferenciar dos tipos de uso de la firma electrónica, que influyen
en el desarrollo de los clientes de esta.
- Ejecución
en estaciones de trabajo
- Ejecución
en servidores de aplicaciones J2EE
2. Ejecución en estaciones de trabajo
En este gráfico se muestra la arquitectura de la API de firma digital en el
uso en estaciones de trabajo
Como se ve, la API consta de un fichero jar en la parte cliente (signaturacaib.core-api.jar
o signaturacaib.core-api.jar [i]), un fichero jar en el directorio de
extensiones de la máquina virtual y una serie de archivos (jar y dll) en el
subdirectorio lib/signaturacaib de la máquina virtual.
La instalación de la API de firma se encarga de incluir los ficheros en lib/ext
y en lib/signaturacaib.
- Es
responsabilidad del desarrollador o distribuidor de la aplicación incluir
la biblioteca (signaturacaib.core-api.jar o signaturacaib.core-api-unsigned.jar[ii])
en la aplicación
- Es
responsabilidad del cliente o de su departamento de informática incluir en
el sistema operativo de su ordenador los drivers de los dispositivos
(lectores, tarjetas,..))
2.1. Ejecución del API de firma mediante Applets
En
este apartado se explica como preparar un applet que utilize el API de firma
2.1.1. Control de versiones mediante extensiones de Java
Para gestionar automáticamente la instalación e actualización de la API de
firma, podemos aprovechar el mecanismo de extensiones de Java [iii].
Para ejecutar el API de firma en un applet, utilizando el mecanismo de
extensiones de Java, se ha añadir un fichero Manifest (extensión mf, por
ejemplo applet.mf) con el siguiente contenido:
Manifest-Version:
1.0
Main-Class:
es.caib.signatura.client.applet.SignApplet
Extension-List:
SignaturaCaib
SignaturaCaib-Extension-Name:
es.caib.signatura
SignaturaCaib-Specification-Version:
2.5.0
SignaturaCaib-Implementation-Version:
2.5.0
SignaturaCaib-Implementation-Vendor-Id:
es.caib
SignaturaCaib-Implementation-URL:
http://www.caib.es/signaturacaib/signatura-installer.jar
Cabe notar que no es necesario firmarlo (i)
2.1.2. Control de la versión de ejecución de Java
Ejecución de applets en versión 1.5 de Java, en Internet Explorer y en
Firefox.
El código HTML necesario es el siguiente:
<object classid="clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA"
codebase="http://java.sun.com/update/1.5.0/jinstall-1_5_0_12-windows-i586.cab"
width="700"
height="300" align="baseline" >
<param name="code"
value="classe" />
<param name="archive"
value="fitxer jar" />
<comment>
<embed
type="application/x-java-applet;version=1.5"
width="700"
height="300" align="baseline"
code="classe"
archive="fitxer jar"
pluginspage="http://java.sun.com/j2se/1.5.0/download.html">
<noembed>
No te suport per applets
Java 2 SDK, Standard Edition v 1.5 ! !
</noembed>
</embed>
</comment>
</object>
Internet
Explorer:
En IE, la localización de la máquina virtual de java se hace mediante la
tecnologia Active X. Indicamos el classid del objeto ActiveX que se
encarga de incrustar el applet en la página y si IE no lo encuentra, lo
descarga de la url indicada en el parámetro codebase. Por lo tanto, si
no está instalada la versión correcta, no estará definido el objeto
correspondiente y se solicitará su instalación.
A la hora de solicitar la instalación, el funcionamiento es diferente si
tenemos o no instalada la versión 6 de Java. Si no tenemos instalada la versión
6 del JRE, el sistema no tiene definido el classid, entra en funcionamiento el
sistema estandar de tratamiento de tags object con clsid desconocido y
descargará directamente el fichero de instalación que le hemos indicado en el
parámetre codebase (http://java.sun.com/update/1.5.0/jinstall-1_5_0_12-windows-i586.cab)
y realizará la instalación de esta versión (mostrando un cuadro de aviso).
Si tenemos instalada la versión 6 del JRE, el JRE tiene definido el classid
en el sistema aunque sabe que no tiene instalada ninguna versión 1.5, y nos
lleva a la página de descargas de la versión 1.5 de Sun, sin tener en cuenta el
parámetro codebase, para descaregarnos la última versión del JRE.
El classid indicado (CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA)
corresponde a un classid genérico que indica que queremos ejecutar el applet en
una máquina virtual de la versión 1.5.xxx (ver http://java.sun.com/javase/6/webnotes/family-clsid.html).
Firefox:
En FF, seleccionamos la versión de la JVM indicando el type. FF
trata el contenido de los tags embed de forma diferente, a través de plugins.
Los plugins son bibliotecas dinámicas que se encuentran en el subdirectorio plugins
del directorio de instalación de FF y que en el momento de arrancar el
navegador, FF carga. Cada plugin soporta uno o más mime types. Escribiendo about:plugins
en la barra de direcciones de FF podemos ver los plugins instalados y los mime
types soportados.
FF para MSWindows es capaz, además, de localizar una serie de plugins en
localizaciones estandar del sistema de ficheros, por ejemplo los de Windows
Media Player y los de Java. El problema es que cuando se hace esta detección
automática, no se tiene en cuenta el plugin que trata los mime types que
permiten hacer static versioning (ejecutar un applet en una versión concreta de
JRE). El resultado es que según las versiones de la JRE de Java que tengamos
instaladas en nuestra máquina, es possible que FF no reconozca el mime type application/x-java-applet;version=1.5 como uno
de los que tiene instalados (sobretodo si tenemos instalado también el JRE
6.0). Si tenemos este problema (JRE 1.5 instalado y FF no lo reconoce) tenemos
que copiar la DLL NPJPI150_11.dll desde el directorio bin de la
máquina virtual (por ejemplo, C:\Archivos de programa\Java\jre1.5.0_12\bin)
al directorio plugins de FF (C:\Archivos de programa\Mozilla
Firefox\plugins).
En entornos con distribución automática de software, este fichero se puede
copiar directamente, puesto que no tiene ninguna contraindicación.
Más
información:
- http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/using_tags.html
- http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/version.html
- http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/contents.html
2.2. Ejecución del API de firma mediante Java Web Start
Para incorporar una aplicación que use el API de firma mediante Java Web
Start se podría utilizar el mecanismo de extensiones para Java Web Start, pero
debido a bugs encontrados y los conflictos que genera, se recomienda no
utilizarlo.
Para el control de versiones de la API debemos incluir el jar cliente. En
el siguiente ejemplo siempre intentará utilizar la última versión de la API:
<resources>
<jar href="http://www.caib.es/signaturacaib/signaturacaib.core-lastest-api-signed.jar"/>
<jar href="mi-aplicacion.jar"
main="true" />
<resources>
Cuando la aplicación intente inicializar el API, se comprueba si está
instalada la versión correcta. En caso contrario se lanza una excepción
UpgradeNeededException, y se puede invocar al instalador de la siguiente
manera:
public static Signer
getSigner() {
SignerFactory sf = new SignerFactory();
try {
return sf.getSigner();
} catch (UpgradeNeededException e) {
e.printStackTrace();
try {
showMessageError
("upgradeneeded");
try {
JNLPLauncher.invoke(e.getUrl());
} catch (NoClassDefFoundError e1) {
e1.printStackTrace();
}
} catch (Exception e1) {
e1.printStackTrace();
}
}
System.exit(0);
return null;
}
3. Ejecución en servidores de aplicaciones J2EE
Es importante diferenciar qué configuración de carga de clases se establece
para las aplicaciones J2EE que utilizan el API de firma:
- Aplicaciones
con classloader propio (Java2parentDelegation=false)
- Aplicaciones
sin classloader propio (Java2parentDelegation=true)
Esta configuración es importante para saber si la librería cliente de la
API debe estar o no en el classpath de la aplicación.
|
|
|
Como se puede apreciar, en el caso en que la aplicación tiene classloader
propio, no debe incluirse en el classpath de la aplicación J2EE, la librería
cliente de la API de firma, por conflictos entre los classloaders. Tampoco debe
invocarse al SignerFactory.getSigner() para inicializar la API, sinó que debe
invocarse directamente new CAIBSigner();