xml-utils.com

decharlas.com es una iniciativa abierta que persigue la difusión de las últimas tecnologías en programación, desarrollo web y seguridad.

El objetivo de este nuevo proyeto en el que nos hemos embarcado, es ofrecer charlas gratuitas mensualmente que sirvan para que los estudiantes y los desarrolladores en general se inicien en los últimos frameworks, tecnologías y entornos de desarrollo.

Las charlas, las cuales se realizarán en las instalaciones de la Universitat Jaume I de Castellón, serán totalmente gratuitas y estarán accesibles a través de la web de decharlas.com.

Este proyecto arranca con mucha ilusión y una colaboración muy interesante. El día 1 de Marzo a las 18:00 y el día 2 de Marzo a las 17:00, disfrutaremos de un conferencia y de un taller práctico sobre TDD y jUnit.

Este taller, impartido por Carlos Ble (autor del libro en castellano Diseño Ágil con TDD), nos ofrecera una visión de como se desarrolla software mediante el uso iterativo de ejemplos definidos por el cliente, en contraposición a los métodos de análisis tradicional. Por otra parte, en el taller práctico, podremos aprende a utilizar el framework JUnit para escribir tests unitarios y otros tests esenciales para el equipo de desarrollo.

Para inscribiros sólo teneis que enviar un correo a contacto@decharlas.com.

Para más información de esta y otras charlas, consultad nuestra web o seguidnos en twitter.

Os esperamos!!!!

Con el fin de conocer más a fondo los nuevos entornos y tecnologías relacionadas con el desarrollo de aplicaciones Web, se presenta desde la Universitat Jaume I de Castellón, la tercera edición del “Curso de especialización en desarrollo web avanzado”. Este año totalmente online !!!

En esta tercera edición prevista desde Noviembre del 2009 a Junio de 2010, se abordarán las siguientes temáticas:

• - Web 2.0: Conceptos e implicaciones
• - Activos de información: Gestión, protección y control
• - Herramientas y nuevos entornos de desarrollo: Wiki, Subversion, Eclipse, Trac
• - Tecnologías base de cliente: XHTML/XML, CSS, JavaScript, SVG en cuanto a las tecnologías base y algunos frameworks de cliente rico como Prototype, JQuery o ExtJS
• - Tecnologías de servidor: PHP y Java
• - Seguridad en entornos web
• - Arquitecturas orientadas a servicios: SOA, Web Services, WSDL y REST

Para más información, se encuentra disponible la página del curso donde, además, se pueden ver algunos ejemplos descargables de los materiales proporcionados:

http://cursowebavanzado.uji.es/
Fundación Universitat Jaume I – Empresa

Os esperamos!!!

Según la especificación del estándar XML Signature del W3C, las firmas “enveloped” son aquellas que están embebidas en los datos originales, de forma que son capaces de excluir su contenido a la hora de verificar el documento original.

Destacan por tener siempre definida una referencia (Reference), con el valor establecido del atributo URI a cadena vacia:

<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue></DigestValue>
</Reference>


Ejemplo de una firma “enveloped”:

El problema es que cuando tenemos más de una firma de este tipo en un mismo documento, es necesario que cada una se excluya a si misma y a las demás firmas a la hora de calcular cualquier digest. Con la transformación “enveloped”, sólo se elimina la propia referencia, quedando en el documento el resto de firmas y haciendo que los cálculos de los digest sean incorrectos.

Para resolver este problema, debemos utilizar XPath Filtering.

Según la especificación, el filtrado XPath en una transformación que nos permite quedarnos con el conjunto de nodos necesario para poder calcular de forma correcta la firma.

En nuestro caso, sustituyendo la transformación “enveloped” por un correcto filtrado, podemos soportar múltiples firmas “enveloped” en un mismo documento:

<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<XPath xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
not(ancestor-or-self::dsig:Signature)
</XPath>
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue></DigestValue>
</Reference>


Si estamos desarrollando en Java, podemos generar este tipo de referencia de la siguiente forma:

Transform transform = fac.newTransform(Transform.XPATH, new XPathFilterParameterSpec(
"not(ancestor-or-self::dsig:Signature)", Collections.singletonMap("dsig", XMLSignature.XMLNS)));
Reference ref = fac.newReference("", fac.newDigestMethod(DigestMethod.SHA1, null),
Collections.singletonList(transform), null, null);

Maven generators es el nombre que le he dado a un nuevo proyecto que he abierto en Google Code y que intenta hacer una primera recopilación de scripts de Maven para la generación de distintos tipos de salida, de forma que sea muy sencillo incorporar estas funcionalidades a nuestros proyectos.

En esta versión, podremos generar:

• Clientes de acceso a Web Services a partir de un WSDL (soporta Axis2 y JAX-WS)
• Clases de manejo de ficheros XML (marshall y unmarshall) con JAXB
• Clases de manejo y persistencia de ficheros XML (marshall, unmarshall y almacenamiento con JPA) con HyperJAXB3
• Clases de mapeo objeto/relacional con JPA e Hibernate

El proceso de generación siempre produce la salida en el directorio “target”, pudiéndose configurar en todos los casos el “package” de destino con el parámetro “-Dpackage=xxx”.
El primer paso en muchos de ellos es incluir el fichero a generar en el directorio “src/main/resources” y luego ejecutar el script de Maven asociado (todos cuentan con un README.txt explicativo con los pasos a seguir).

Hasta ahora, el formato ODF contaba con la posibilidad de poder almacenar una firma digital asociada en formato XML Signature.

Gracias a esta característica, podemos garantizar la identidad del autor o persona que ha generado el documento y lo ha firmado, y la integridad del mismo asegurando que no haya sido alterado.

Por otra parte, si queremos asegurar que el certificado utilizado es válido en el momento de la firma o establecer la fecha y hora de firma de forma feaciente, es necesario utilizar un formato de firma XML más avanzado que XML Signature.

Todos estos requisitos son cubiertos por el estándar XAdES, que en su perfil XAdES-X-L extiende la información criptográfica especificada por XML Signature y le añade la respuesta OCSP del servicio de validación de certificados y el sello de tiempo, entre otros muchos atributos. Es por todo esto que XAdES ha sido elegido como el formato de firma base para la generación de facturas electrónicas en formato Facturae.

Así pues, gracias al nuevo soporte de XAdES que tendrá ODF 1.2, podremos contar con todas estas nuevas funcionalidades que tan importantes son para la adminsitración electrónica y la preservación de documentos digitales.

Adicionalmente, es interesante destacar que PDF, vía la generación de firmas digitales en formato CMS, también es capaz de almacenar un sello de tiempo generado por una autoridad certificadora.

Enlace a la noticia original:

http://homembit.com/2009/01/firmas-digitales-en-el-odf-12-seran-compatibles-con-la-icp-brasil.html

Después de una muy larga espera y muchos intentos de tener un toolkit unificado para el manejo del estándar ODF (OpenDocument Format), IBM y Sun Microsystems han anunciado en la OpenOffice.org Conference 2008 el lanzamiento de un nuevo site que unificará todos los esfuerzos desplegados alrededor de ODF:

http://odftoolkit.org/

Dentro del ámbito de Java, han habido dos intentos reseñables de ofrecer un API “pura” para el manejo de ODF, es decir, que no necesitaran acceder a una instalación de OpenOffice corriendo como un servicio:

- odf4j. Implementación dentro del marco de desarrollo de OpenOffice.
- jOpenDocument. Implementación muy completa, con soporte incluso para la conversión de hojas de cálculo a PDF.

Posteriormente, la gente de Sun Microsystems tomaron el control del proyecto odf4j y lo rediseñaron por completo. Con una nueva arquitectura de capas y el “empujón” de tener un grupo de expertos desarrolladores detrás, nació ODFDOM.

Con este nuevo toolkit se ha conseguido unificar esfuerzos de forma que, jOpenDocument ha pasado a basarse en ODFDOM en lugar de realizar su propio mantenimiento del acceso al modelo de objetos de los documentos ODF.

Sólo añadir que, para los desarrolladores .NET, también existe una implementación oficial dentro del proyecto “ODF Toolkit” y se llama AODL.