Archivos del sitio
C# / ASP.NET : Firma digital y autenticación con Viafirma (II)
En este artículo muestran los pásos a seguir para utilizar los servicios de firma digital ( XAdes, Facturae, …), autenticación (FNMT, Firma Profesional, ANCERT, …) y verificación de validez de certificados ( OCSP, CRLs, …) desde aplicaciones ASP.NET gracias a Viafirma.
1- Añadir las dependencias necesarias
Es necesario que incorporemos al proyecto las siguientes dlls incluidas en el kit de desarrollo de Viafirma: DotNetOpenId.dll, log4net.dll y ViafirmaClientDotNet.dll.
Por otro lado también necesitaremos añadir el directorio “viafirma” y que contiene los ficheros:
- Default.aspx: con los métodos que deben ser sobreescritos con el comportamiento específico a ejecutar cuando finalice el proceso de firma.
- viafirmaStyle.css: con la apariencia que viafirma adoptara para el proceso de autenticación o firma. Este css puede ser adaptado a la identidad corporativa de la aplicación cliente.
- xrds.aspx: necesario para el correcto funcionamiento de la comunicación OpenID.
2- Creamos una página de ejemplo desde la que realizar la firma
Creamos una primera página aspx en la que simplemente colocaremos un botón de acción asociado a un controlador de página que utilizará el API de Viafirma para firmar digitalmente un fichero de ejemplo con el certificado digital al usuario.
El código de la aplicación de ejemplo queda como el siguiente:
<%@ Page Language=”C#” Inherits=”AplicacionEjemploClienteViafirma.Default” %>
<html>
<body>
<h2>Ejemplo de integración Viafirma con .Net</h2>
<form id=”form1″ runat=”server”>
<p>Pruebe la autenticación</p>
<asp:button id=”firmarButton” runat=”server” text=”Firmar un documento de ejemplo con Viafirma” onClick=”FirmarButton_Click” />
</form>
</body>
</html>
3- Implementar el método FirmarButton_Click
En este método simplemente indicaremos al cliente de viafirma cuál es la url pública de acceso a Viafirma, cuál es la url de acceso al servicio web de Viafirma, y registraremos un fichero para su firma.
public void FirmarButton_Click(object sender, EventArgs e){ // Configuramos el cliente de viafirma ( En una aplicación real esto se realiza al iniciar la aplicación) ViafirmaClientFactory.Init(“http://viafirma.viavansi.com/viafirma”, http://viafirma.viavansi.com/viafirma); // Recuperamos / Generamos el contenido del documento a firmar. ( Como ejemplo generamos un txt )byte[] datos_a_firmar = System.Text.ASCIIEncoding.ASCII.GetBytes(“Contenido del documento firmado”); // Enviamos a firmar el documento ViafirmaClient clienteViafirma = ViafirmaClientFactory.GetInstance(); // Registramos el documento que deseamos firmar. Obteniendo un identificador temporal. string idTemporalFirma = clienteViafirma.PrepareFirmaWithTypeFileAndFormatSign(“FicheroEjemplo.txt”, typeFile.txt, typeFormatSign.XADES_EPES_ENVELOPED, datos_a_firmar); System.Console.Write(“idTemporalFirma: “ + idTemporalFirma); // Iniciamos el proceso de firma redireccionando al usuario a Viafirma interactuando con el usuario.. clienteViafirma.Sign(idTemporalFirma); }
Con este simple código ya conseguimos que nuestra aplicación ASP.NET utilice Viafirma para que sea ésta la responsable de solicitar, validar, recuperar el certificado o DNI electrónico del usuario y firmar el documento digitalmente. En este ejemplo se ha realizado la firma de un fichero de texto utilizando en formato XADES, pero de una forma muy similar se podría haber optado por realizar la firma de un pdf o de una factura electrónica.
Una vez que el proceso termine, Viafirma devolverá el control a la aplicación ASP.NET retornando todos los datos obtenidos del certificado, junto con el identificador de firma asociado al documento firmado.
Obtener los datos de respuesta
Una vez que Viafirma obtenga los datos del certificado de usuario invocará al método ProcessResponseSign, que se encuentra en el fichero Default.aspx dentro del directorio viafirma. Lo único que tendremos que hacer es sobreescribir dicho método con el comportamiento deseado y recuperar todos los datos de la firma del objeto FirmaInfoViafirma.
En este ejemplo, si la firma ha sido correcta, redireccionamos al usuario a una página de destino.
override public void ProcessResponseSign(Viafirma.Estado estado,Viafirma.FirmaInfoViafirma firma){
Viafirma.Log.Debug(“Firma Viafirma realizada correctamente.”);
// Aquí ya tenemos todos los datos asociados al cliente y a su firma.
//redireccionamos al usuario a la p gina destino considerando el usuario ya ha finalizado la firma.
if(Viafirma.Estado.OK== estado){
Session[“resultadoFirma”]= firma;
Uri url=new Uri(HttpContext.Current.Request.Url, HttpContext.Current.Response.ApplyAppPathModifier(“~/resultadoFirma.aspx”));
HttpContext.Current.Response.Redirect(url.AbsoluteUri);
} else{
// Hay problemas al firmar.
}
}
A continuación se muestran algunas capturas de pantalla de la aplicación de ejemplo ASP.NET en acción:
Página inicial de la aplicación de ejemplo: ( contenida en el Kit de desarrollo de Viafirma)
La aplicación ASP.NET interactuando con Viafirma para realizar la firma.
La aplicación ASP.NET muestra algunos de los datos retornados tras el proceso de firma.
Implementación de la fórmula Haversine en Java
El algoritmo Haversine sirve para calcular la distancia entre dos puntos de los que conocemos su longitud y latitud. A continuación incluimos un método Java que implementa esta fórmula devolviendo la distancia en metros:
private static int calculateDistanceByHaversineFormula(double lon1, double lat1,
double lon2, double lat2) {
double earthRadius = 6371; // km
lat1 = Math.toRadians(lat1);
lon1 = Math.toRadians(lon1);
lat2 = Math.toRadians(lat2);
lon2 = Math.toRadians(lon2);
double dlon = (lon2 - lon1);
double dlat = (lat2 - lat1);
double sinlat = Math.sin(dlat / 2);
double sinlon = Math.sin(dlon / 2);
double a = (sinlat * sinlat) + Math.cos(lat1)*Math.cos(lat2)*(sinlon*sinlon);
double c = 2 * Math.asin (Math.min(1.0, Math.sqrt(a)));
double distanceInMeters = earthRadius * c * 1000;
return (int)distanceInMeters;
}
En nuestro caso ha sido utilizado para evaluar la distancia a un establecimiento determinado desde nuestra posición actual (calculada mediante GPS).
Leyendo un feed OpenSearch con código Java
De forma muy resumida, OpenSearch es una colección de formatos abiertos y estándares desarrollados por A9 (Amazon), que persiguen resolver 2 escenarios principalmente:
- Caso 1: Permitir a una aplicación publicar de una forma estándar resultados de búsqueda; estos resultados pueden ser consumidos posteriormente por una aplicación cliente. Se basa en un metamodelo estandarizado publicado bajo una fuente de sindicación estándar como RSS o Atom. Podemos ver un ejemplo de resultado de búsqueda en formato OpenSearch en esta URL de indeed.com.
- Caso 2: Describir (autodescribir) servicios de búsqueda. Es lo que utiliza por ejemplo Firefox 3 para ofrecernos búsquedas inteligentes.
En este post vamos a describir cómo leer resultados de búsqueda en formato OpenSearch (caso 1). Para el caso 2, recomendamos la lectura de un post de 11870.com que describe a la perfección cómo describir nuestro buscador.
Si nos fijamos en el código fuente de respuesta de la URL comentada de indeed, veremos que en este caso se está devolviendo sobre RSS una información general sobre la búsqueda más un conjunto de resultados de búsqueda (items), los cuales pueden ser incluso geolocalizados.
En Java, este RSS (o Atom) podría ser leído con cualquier intérprete de XML, o mejor con alguna librería específica de este tipo de feeds, como Rome o Apache Abdera, o mejor aún, con librerías específicas para OpenSearch. En nuestro caso, debíamos leer la respuesta del API de 11870.com, dentro de un proyecto en el cual deseábamos proponer establecimientos propuestos por los usuarios que estén cercanos a nuestra localización.
A este respecto, cuando he hecho la búsqueda de librerías Java, personal he tenido una sensación agridulce. Si bien los desarrolladores Java solemos ser unos verdaderos privilegiados en cuanto a lo que se refiere a disposición de API’s, en ciertos casos relacionados con web semántica o API’s de web 2.0 tengo la sensación de que otras arquitecturas de desarrollo como PHP, Python o RoR a veces tienen cierta ventaja. En el caso de Java todo son versiones de incubadora, 0.X, etc.
En el caso de librerías Java, una rápida búsqueda nos llevó a decidirnos entre Rome (Sun) y Apache Abdera, escogiendo este último por disponer de mejores ejemplos de los que partir. Además dentro de los committers de Abdera está el supercrack David Calavera, desarrollador de la omnipresente 11870.com.
A continuación incluiremos unos pequeños recortes de código que muestran como leer la respuesta OpenSearch mediante Abdera. En primer lugar, necesitaremos disponer de las librerías. Para ello (en el caso de Maven) incluiremos estas dependencias en nuestro pom.xml:
<dependency>
<groupId>org.apache.abdera</groupId>
<artifactId>abdera-client</artifactId>
<version>0.4.0-incubating</version>
</dependency>
<dependency>
<groupId>org.apache.abdera</groupId>
<artifactId>abdera-extensions-opensearch</artifactId>
<version>0.4.0-incubating</version>
</dependency>
Para poder resolver estas dependencias incluiremos los repositorio Incubating y Snapshot de Apache dentro de <repositories>:
<repository>
<id>apache-incubating</id>
<name>Apache Incubating Repository</name>
<url>http://people.apache.org/repo/m2-incubating-repository/</url>
</repository>
<repository>
<id>apache-snapshots</id>
<name>Apache Snapshot Repository</name>
<url>http://people.apache.org/repo/m2-snapshot-repository/</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
</repository>
Dado una dirección URL (String urlQuery) donde esté publicada una consulta que responde OpenSearch, podremos invocarla con el siguente código:
Abdera abdera = new Abdera();
Parser parser = abdera.getParser();
URL url = new URL(urlQuery);
Document<Feed> doc = parser.parse(url.openStream(), urlQuery);
Feed feed = doc.getRoot();
Podemos recuperar ciertas propiedades de la respuesta de OpenSearch:
IntegerElement totalResults = feed.getExtension(OpenSearchConstants.TOTAL_RESULTS);
int resultados = totalResults.getValue();
Del mismo modo se pueden recuperar datos como el número de items por página (OpenSearchConstants.ITEMS_PER_PAGE) o el índice inicial de la respuesta, útil cuando hay paginación (OpenSearchConstants.START_INDEX. Es decir, podemos obtener datos OpenSearch del feed mediante feed.getExtension().
A continuación mostramos cómo iterar los items de respuesta del feed:
for (Entry entry : feed.getEntries()) {
System.out.println(”Title: “+entry.getTitle());
System.out.println(”Summary: “+entry.getSummary());
System.out.println(”Id: “+entry.getId().toString());
System.out.println(”Id: “+entry.getId().toString());
}
También podemos evaluar para cada item (resultado de búsqueda) el valor de extensiones a OpenSearch. Por ejemplo, podemos pretender recuperar los datos de geolocalización en formato GeoRss. Para ello utilizaríamos un código como el que sigue:
QName qnameWhere = new QName(”http://www.georss.org/georss/10″,”where”, “georss”);
Element where = entry.getExtension(qnameWhere);
try {
String geoPos = where.getFirstChild().getFirstChild()
.getText();
String[] posicion = geoPos.split(” “);
if (posicion.length == 2) {
System.out.println(”latitud: “+posicion[0]);
System.out.println(”longitud: “+posicion[1]);
}
} catch (Exception e) {
e.printStackTrace();
}
Es decir, podemos recuperar el valor de un parámetro de una extensión invocando a entry.getExtension, pasando como parámetro un objeto de tipo QName, instanciado como indicamos en el código anterior.
En definitiva, hemos hecho una breve introducción a OpenSearch y mostrado código de ejemplo para interactuar con una respuesta OpenSearch mediante Apache Abdera.
C# / ASP.NET : Firma digital y autenticación con Viafirma (I)
Aunque Viafirma ofrece todos sus servicios mediante métodos estándar ( Servicios Web y OpenID), hemos desarrollado un cliente para .Net 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 dlls necesarias al proyecto y cómo hacer uso de los diferentes servicios de firma digital (XAdES, Facturae, PDF sign, etc… ), autenticación (FNMT, Camerfirma, Firma profesional, DNIe, etc…), custodia (integridad, etc…) y verificación (CRLS, OCSP, etc…).
1- Añadir las dependencias necesarias
Es necesario que incorporemos al proyecto las siguientes dlls incluidas en el kit de desarrollo de Viafirma: DotNetOpenId.dll, log4net.dll y ViafirmaClientDotNet.dll.
Por otro lado también necesitaremos añadir el directorio “viafirma” y que contiene los ficheros:
- Default.aspx: con los métodos que se ejecután cuando el proceso de autenticación o firma finalice.
- viafirmaStyle.css: con la apariencia que viafirma adoptara para el proceso de autenticación o firma.
- xrds.aspx: necesario para el correcto funcionamiento de la comunicación OpenID.
2- Creamos la página de acceso a la autenticación.
Creamos una primera página aspx en la que simplemente colocaremos un botón de acción asociado a un controlador de página que utilizará el API de Viafirma para autenticar con certificado digital al usuario..
El código de la aplicación de ejemplo queda como el siguiente:
<%@ Page Language="C#" Inherits="AplicacionEjemploClienteViafirma.Default" %> <html> <body> <h2>Ejemplo de integración Viafirma con .Net</h2> <form id="form1" runat="server"> <p>Pruebe la autenticación</p> <asp:button id="autenticarButton" runat="server" text="Autenticar al usuario con certificado o dnie" onClick="autenticarButton_Click" /> </form> </body> </html>
3- Implementar el evento autenticarButton_Click
En este método simplemente indicaremos al cliente de viafirma cuál es la url pública de acceso a Viafirma y cuál es la url de acceso al servicio web de Viafirma.
public void autenticarButton_Click(object sender,EventArgs e){
// Configuramos el cliente de viafirma ( En una aplicación real esto se realiza al iniciar la aplicación)
ViafirmaClientFactory.Init("http://pruebas.viavansi.com/viafirma","http://pruebas.viavansi.com/viafirma");
// Obtenemos una instancia del cliente e iniciamos la autenticación
ViafirmaClient clienteViafirma=ViafirmaClientFactory.GetInstance();
clienteViafirma.Autenticate();
}
Con este simple código ya conseguimos que nuestra aplicación ASP.NET utilice Viafirma para que sea ésta la responsable de solicitar, validar y recuperar el certificado o DNI electrónico del usuario. Una vez que el proceso termine, Viafirma devolverá el control a la aplicación ASP.NET retornando todos los datos obtenidos del certificado.
Obtener los datos de respuesta
Una vez que Viafirma obtenga los datos del certificado de usuario invocara al método ProcessResponseAutenticacion, que se encuentra en el fichero Default.aspx dentro del directorio viafirma. Lo único que tendremos que hacer es sobreescribir dicho método con el comportamiento deseado y recuperar todos los datos del certificado del objeto UsuarioGenericoViafirma.
En este ejemplo si la autenticación ha sido correcta redireccionamos al usuario a una página de destino.
override public void ProcessResponseAutenticaction(Viafirma.Estado estado,Viafirma.UsuarioGenericoViafirma usuario){
Viafirma.Log.Debug("Autenticación Viafirma realizada correctamente. Resultado:"+ estado);
// Aquí ya tenemos todos los datos asociados al cliente. y redireccionar al usuario a la página destino
// considerando el usuario ya autenticado.
if(Viafirma.Estado.OK== estado){
Session["resultadoAutenticacion"]= usuario;
Uri url=new Uri(HttpContext.Current.Request.Url, HttpContext.Current.Response.ApplyAppPathModifier("~/resultadoAutenticacion.aspx"));
HttpContext.Current.Response.Redirect(url.AbsoluteUri);
}else{
// Hay problemas al validar.
}
}
Próximamane: C# / ASP.NET : Firma digital y autenticación con Viafirma (II)
La liga de futbolín Viavansi 2008-2009
Hemos empezado una nueva liga de futbolín, podéis seguirla en http://www.gesliga.com/Clasificacion.aspx?Liga=261
Conclusiones finales. Eligiendo nuestro entorno de Integración Continua (V).
Después de una serie de artículos que se iniciaron con Eligiendo nuestro entorno de Integración Continua (I) , tenemos las conclusiones finales de nuestra comparativa.
- Tabla resumen
A modo de resumen hemos agrupado en una sola tabla todos las parámetros evaluados en la comparativa, para permitirnos una comparación rápida entre las diferentes herramientas.
|
Apache |
LuntBuild |
Hudson |
|
| Instalación | |||
| Documentación de instalación |
Suficiente |
Buena |
Buena. |
| Dificultad de la instalación |
Fácil. |
Fácil. |
Muy |
| Configuraciones avanzadas |
Compleja |
Fácil |
Fácil |
| Administración | |||
| ¿permite la configuración completa desde la interfaz Web? |
Sí. |
Completa |
Completa |
| Documentación oficial de Administrador |
Suficiente |
Suficiente |
Buena. |
| ¿permite copias de Seguridad desde la herramienta? |
No |
Sí |
No |
| Mantiene un histórico de compilaciones (build) |
Sí |
Sí |
Sí |
| Gestión de tareas programadas |
Sí |
Sí |
Sí |
| Rendimiento |
Bueno |
Muy |
Muy |
| Seguridad | |||
| Gestión de permisos basados en perfiles |
Sí |
Sí, |
Sí |
| Gestión de permisos específicos por proyecto |
Sí |
Sí |
Sí |
| Facilidad de configuración de la seguridad |
Fácil |
Fácil |
Muy |
| Integración con sistemas externos |
|||
| Integración con Sistemas de control de Versiones |
Suficiente |
Muy |
Muy |
| Integración con plataformas de gestión de incidencias (bugtrackers) |
Mala |
Mala |
Regular |
| Integración con herramientas de generación de informes (reporting) |
Buena, |
Buena |
Muy |
| Desarrollo de nuevos plugins o mecanismos de extensión |
Complejo |
Suficiente |
Muy |
| Integración con herramientas de testeo |
Buena |
Buena |
Muy |
| Tipos de proyectos Soportados |
|||
| proyectos Java |
Muy |
Muy |
Excelente |
| proyectos No Java |
Mala. |
Mala. |
Buena, |
|
Facilidad |
|||
| Documentación de usuario |
Buena |
Buena |
Muy |
| Interfaz |
Fácil |
Complejidad |
Muy |
| Estabilidad | |||
| Estabilidad general de la herramienta |
Buena |
Buena |
Buena |
| ¿permite compilación distribuida? |
No |
Sí |
Sí |
| ¿permite la gestión de hilos de ejecución? |
No |
Sí |
Sí |
- Conclusiones finales.
Sin duda nuestra propuesta se inclina por Hudson. Brevemente vamos a enumerar y resumir (de entre los detalles de esta comparativa) ciertos aspectos que hacen inclinar la balanza hacia este software:
- Extensibilidad. La posibilidad de desarrollar plugins que permitan adaptar e inyectar funcionalidad de forma personalizada es una característica casi imprescindible. Apache Continuum no dispone de esta posibilidad de integrar plugins (deben ser plugins Maven, utilizados específicamente en cada uno de los proyectos Java), lo cual prácticamente hace descartar esta plataforma. LuntBuild dispone de ciertas opciones de inyección de código, si bien a este respecto las mejores características las tiene Hudson.
- Calidad de la documentación. En esta materia Hudson también dispone de la mejor documentación, por delante de LuntBuild y Continuum.
- Integración de resultados de plugins (centralizados o Maven) en pantalla. Un aspecto de interés es que el resultado de los diversos plugins pueda verse en la interfaz web de la aplicación. Tan sólo Hudson proporciona este nivel de integración por defecto.
- Sistema de seguridad y permisos. En esta funcionalidad tan importante lideran la comparativa Hudson y Continuum. Ambas disponen de la posibilidad de gestión de permisos basados en perfiles, y posibilidad de personalizar los permisos por proyectos. Continuum puede requerir modificaciones en ficheros de configuración y reinicio del sistema, mientras que Hudson permite configuración integral en pantalla.
- Estabilidad. Las tres plataformas disponen de buenas características de estabilidad, si bien destacan Hudson y LuntBuild, que permiten la gestión multihilo y compilación distribuida.
- Soporte de la comunidad. A este respecto lideran la comparativa tanto Hudson como Continuum, desarrollos de Sun y Apache respectivamente.
Como se puede observar, Hudson auna las principales características que nosotros esperabamos de un sistema de Integración Continua, y por ello es nuestra propuesta y elección para servir de plataforma base en la infraestructura de desarrollo.
Programando para iPhone
A nivel personal he comenzado a colaborar en el blog Actualidad iPhone con una serie de artículos de iniciación al desarrollo de aplicaciones nativas y webapps para iPhone. No tendrán el detalle técnico que suele perseguir este blog, pero al menos puede servir de punto de partida para los lectores que quieran empezar desde cero a hacer unos pinitos con el ¿mejor? gadget de Apple…
¿Quieres trabajar en VIAVANSI?
En VIAVANSI seguimos buscando técnicos que encajen en nuestro grupo de trabajo, y hemos pensando que probablemente los lectores de nuestro blog sean muy adecuados para nosotros. ¿Qué esperamos de nuestros nuevos compañeros?
- Si saben Java, estupendo.
- Si tienen experiencia en los entornos y herramientas de la Junta de Andalucía, mejor.
- Si además entienden los posts técnicos de este blog, has oído hablar de Seam, etc., entonces la repera ;-)
Pero sobre todo esperamos que los nuevos compis encajen en este gran grupo humano. No nos entendáis mal, no esperamos que nadie venga a la entrevista disfrazado de Darth Vader ;-) Pero sí que compartan nuestra pasión por la tecnología y por hacer las cosas bien.
Los candidatos podéis enviarnos vuestro CV a rrhh @ viavansi.com
Gracias!
Hudson. Eligiendo nuestro entorno de Integración Continua (IV).
Nos encontramos ante un software relativamente novedoso, pero que se ha convertido en uno de los referentes en cuanto a sistemas de Integración Continua. Es una herramientas software libre desarrollada en Java y mantenida por Sun Microsystems desde su web java.net. La herramienta puede ser descargada desde https://hudson.dev.java.net/.
- Instalación
La instalación de Hudson es extremadamente sencilla, pudiéndose realizar una evaluación del software utilizando un instalador Java Web Start desde la web del producto. Así mismo, se puede descargar e instalar la aplicación de forma standalone, o se puede desplegar sobre un servidor de aplicaciones mediante el fichero empaquetado hudson.war.
El sistema está pensado para que nunca sea necesario editar ningún fichero de configuración externo, ofreciéndonos una administración web sencilla pero que contempla una configuración visual integral (incluyendo por ejemplo la parametrización de SMTP, base de datos, seguridad, etc.).
La documentación de instalación oficial del producto es buena, e incluye incluso algunos vídeos screencasts. Por otro lado, si en algún momento nos sentimos confundidos con la configuración, el sistema ofrece una completa ayuda en linea y contextual que facilita mucho la tarea de configuración para personas no familiarizadas a priori con este tipo de sistemas.
- Administración, gestión de proyectos
La herramienta ofrece una interfaz muy intuitiva para su administración, por lo que como hemos comentado antes, no será necesario personal especializado para su administración, pudiéndose realizar todas las tareas desde la propia consola web.
La herramienta permite la definición de tareas periódicas desde su interfaz web mediante un editor similar a cron dotado de una completa ayuda contextual.
Por otro lado, durante las pruebas, la migración de los proyectos a Hudson ha resultado ser muy rápida y sencilla, consiguiendo un entorno totalmente configurado y funcional en poco tiempo.
Respecto a su mecanismo de actualización, Hudson es el mejor de los sistemas analizados, ya que sólo es necesario descargar el nuevo empaquetado .war y sustituir el existente, asegurándose la plataforma de mantener la compatibilidad de forma automática. Por otro lado, es el propio Hudson el que nos avisará de la existencia de nuevas versiones, tanto del sistema completo como de sus plugins.
- Seguridad
El sistema ofrece un sistema de seguridad completo y muy flexible, y totalmente configurable desde la consola web, permitiéndonos o bien integrarnos con sistemas externos de autenticación (LDAP, bases de datos externas) o delegar la seguridad en el propio Hudson.
Si optamos por que Hudson gestione la seguridad, dispondremos de múltiples opciones que cubren todo el abanico de necesidades, como seguridad basada en perfiles, asociación de permisos por proyectos o por matriz de acciones.
- Integración con sistemas externos
Hudson ofrece un mecanismo de extensión muy completo, que junto con el gran número de plugins ya existentes le permiten su integración con un gran número de sistemas y herramientas. Por otro lado, aunque está preparado (al igual que Continuum o LuntBuild) para utilizar directamente los plugins Maven, proporciona los mecanismos adecuados para no depender de una correcta configuración de estos plugins en el fichero pom.xml de los proyectos. Esta centralización de la configuración constituye una ventaja muy importante respecto a sus competidores, ya que garantiza que, independientemente de lo contenido en el pom.xml, se puedan ejecutar los procesos de chequeo y validación deseados.
Por otro lado, existe una integración plena entre Hudson y sus plugins. Los resultados de éstos podrán ser visualizados en la herramienta web, incluyendo tanto conclusiones de testeo, estilos, pruebas unitarias, etc… como los resultados de los procesos de despliegue. Nuevamente Hudson es la única plataforma en permitir este tipo de funcionalidad avanzada.
Por otro lado, permite la integración con la mayoría de sistemas de control de versiones (SVN, CVS, etc.), ya sea de base, o mediante la inclusión de los plugins necesarios.
Es de especial interés el mecanismo de instalación y gestión de plugins, ya que la herramienta nos permite la descarga e instalación automática desde su interfaz web, avisándonos incluso de la aparición de nuevas versiones de los mismos de forma automática.
Otro factor muy importante es la completa documentación para poder desarrollar nuestros propios plugins, que nos permitirán adaptar el sistema a las particularidades propias de cada entorno.
También resulta curiosa la integración con sistemas como Twitter, Jabber, etc., que nos permiten hacernos una idea del avanzadísimo nivel de los mecanismos de integración incorporados en la plataforma. Sin duda, esta es la característica en la que más se destaca Hudson frente a Continuum o LuntBuild.
- Tipos de proyectos
Aunque la herramienta esta principalmente enfocada a proyectos Java, gracias sus plugins tiene soporte para gran multitud de formatos como por ejemplo Ivy, Nant, Rake, Ant, Maven, Phing, Shell scripts, y para lenguajes como .Net, Groovy, Rails, PHP.
- Facilidad de uso
La herramienta ofrece una interfaz potente y muy usable, que permite que personal no cualificado o con poca experiencia en este tipo de herramientas se adapte a su uso con facilidad.
La documentación oficial es completa, y junto con la ayuda contextual en todos los elementos de la interfaz hace que la curva de aprendizaje sea muy rápida.
- Estabilidad
Nos encontramos ante un software muy estable, al igual que ocurría con sus dos competidores directos. Prueba de ello es que está siendo utilizado para todos sus proyectos en grupos de desarrollo como JBoss. Como sistema de Integración Continua, tiene una política de publicación de actualizaciones muy dinámica que hace que se liberen versiones cada pocas semanas, lo cual podría ser un inconveniente de no ser por las posibilidades de actualización automática comentadas. A continuación se indican las principales versiones liberadas:
En lo referido al rendimiento, el sistema permite la gestión de hilos de ejecución dedicados a tareas de compilación y la ejecución de compilación distribuidas, lo que le confiere excelentes características de escalabilidad y adaptabilidad al entorno disponible.
-
Hudson 1.256
Julio 2008
Hudson 2.00
Marzo 2008
Hudson 1.100
Abril 2007
- Conclusiones sobre Hudson
La herramienta, gracias a su sistemas de plugins, ha resultado ser muy versátil y fácilmente adaptable a necesidades particulares. Por otro lado, su sencilla interfaz la hacen ideal para su uso por personal no especializado en este tipo de herramientas.
Aunque la herramienta es la más joven de las estudiadas, está teniendo una rápida aceptación y divulgación en el mercado, y ha demostrado completamente su fiabilidad.
Próximamente: Conclusiones finales. Eligiendo nuestro entorno de Integración Continua (V).
Implementando un flujo de firmas en nuestro workflow
A continuación vamos a explicar cómo aprovechar las bondades de tres componentes habituales en nuestros desarrollos para implementar un sencillo flujo de firma de formularios.
Los jugadores son:
- Jbpm 3.2 como motor de workflow.
- Formula 2 como motor de formularios.
- Viafirma 1.3.5 como motor de firma digital.
La aplicación que los implementa está desarrollada con Seam + JSF + JPA.
La Descripción
Básicamente el requisito era el siguiente: un formulario completado por un usuario entraba en un flujo de transiciones en el que distintos departamentos y/o personas tenían que ir aprobándolo con su firma digital.
La solución tradicional con la que contábamos se basaba en recuperar los datos del primer formulario, y en la transición adecuada los mostrábamos para que el firmante pudiera comprobar los datos (tareas).
Esto implicaba un esfuerzo en la redendirización nuevamente de los datos facilitados por el usuario, por lo que decidimos aprovechar las características de los componentes usados para simplicarlo todo.
Solución
Formula2 permite la identificación de los campos creados en el formulario. De esta manera nuestra solución consisitirá en identificar un mismo nombre de campo dentro de un mismo ProcessId.
Una vez asegurado en nuestro proceso esta identificación de campos, ahora toca el turno de Formula2; duplicaremos el formulario original, y modificaremos todos sus campos al tipo ReadOnly, de manera que el firmante no pueda modificar los datos mostrados en el formulario inicial.
Opcionalmente, a esta copia del formulario se le podrán añadir campos adicionales, como por ejemplo, un campo de observaciones o bien otros campos para informar valores necesarios en la siguiente transición.
Esta tarea de modificar cada campo de un formulario podría resultar algo engorrosa, pero solo habrá que hacerlo una vez, ya que la primera copia con todos sus campos “ReadOnly” nos serviría de base para las sucesivas copias que necesitemos, y para estas copias ya no será necesario modificar la propiedad de sus campos.
Resultado
A medida que el diseño del flujo (process-definition) va ejecutando las tareas e invocando los distintos formularios, los actores propietarios de dichas tareas van firmando con su certificado digital los formularios.
El proceso de firma es delegado a nuestro al motor de firma VIAFIRMA. Cuando éste completa la transacción de firma, devuelve todos los datos necesarios a nuestro sistema. En este caso, Jbpm interpreta estos datos de firma como variables del proceso, añadiéndolos como un dato más de la transición.
Como valor agregado, estos datos de firma y los contenidos en el formulario son indexados mediante Lucene (implementando openSearch), y de esta forma ofrecemos al usuario la posibilidad de buscar su proceso por el código de firma que se le informó.
Tras el proceso de firma, se le muestra al usuario una pantalla de recibo, donde se le accede a toda la información del proceso con las distintas opciones:
- Descarga del formulario que fue firmado.
- Descarga del comprobante de firma, con los datos del firmante y de la transacción (fecha, hora y certificado usado).
- Id. de las tarea y proceso.
- Link permanente a su proceso.
- Todo ello apoyado con imágenes bidimensionales como el Qr-Code con el resumen de la firma y el BarCode con el código de la firma.
Posibles Conflictos
Seguro que a alguno ya se le ha pasado por la cabeza un posible conflicto:
¿Qué ocurre si para un mismo ProcessId se ven involucrados 2 formularios que no son copias el uno del otro, pero el identificador que le pusimos al campo es el mismo, por ejemplo ID_PROFESOR?
- si el segundo formulario NO es una copia del primero, pero tiene un campo con el mismo Id., efectivamente nuestro proceso hará que este segundo formulario se renderice con el valor introducido para ese campo en el primer formulario. Pero, al no tratarse de una copia, el campo no será del tipo ReadOnly (o no debiera), por lo que el valor podría ser modificado por el usuario.
- La solución a este tipo de conflictos en nuestro caso: anteponer un identificador del formulario a modo de prefijo en el identificador del campo. Por ejemplo: FRM_9_ID_PROFESOR.
Resumen
Gracias a la funcionalidad de Formula2 para identificar los campos y duplicar formularios conseguiremos una sencilla implementación de un ESCRITORIO DE FIRMA.
- Nos ahorramos construir N formularios.
- Nos ahorramos la lógica para recuperar y renderizar los datos asociados al formulario original y que necesitamos ir mostrando a cada firmante.
Busca esto rápido
Encuentra lo que buscas de forma sencilla usando el buscador.
Categorías
Encuentra artículos a través de sus "tags"
Archivos mensuales
Encuentra artículos según el mes en el que fueron escritos.
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007








