Category: Javahispano

JBoss Seam: render an external xhtml

02 Dic 2011

Humor: evolución del framework perfecto

23 Dic 2010

framework perfecto - 2001

Hace dos años y medio ya comentamos sobre las virtudes de nuestro framework perfecto. Transcurrido todo ese tiempo, el framework sigue dando sus frutos, con resultados bastante didácticos.

http://www.xnoccio.com//es/320-humor-el-framewok-perfecto/ (mayo 2008)

framework perfecto en 2008

framework perfecto - 2001

Feliz navidad y bebed con moderación.

Humor: Nuestros libros de referencia Java

21 Sep 2010


Quizás también te interese conocer nuestro Framework perfecto o como saber cuando una tecnología está desfasada.

Nota: Para los que no capten la sutil diferencia, pueden consultar los originales en Amazon: Cryptography with Java y J2EE Developement without EJB.

Humor: Firma digital en una antigua máquina de escribir Oliveti

01 Sep 2010

En nuestro esfuerzo por ser una plataforma de firma digital universal, nuestro departamento de I+D ha conseguiro ampliar aun más nuestra matriz de compatibilidad consiguiendo realizar una firma digital en una antígua Oliveti!.
El video no tiene desperdicio :p.

De esta forma junto con las plataforma ya soportadas Linux (Firefox, Chrome), MacOS (Safari, Firefox), Windows (Firefox,Chorme, IE 6. IE7, IE8), Android, iPhone, iPad; Ahora incorporamos soporte para Oliveti Linea 98!!

Viafirma ya disponible en Apple Store y Android Market

29 Jul 2010

El componente de Viafirma para Android/iPhone/iPad ya está disponible tanto en la App Store como el Android Market de forma totalmente gratuíta, de esta forma Viafirma se convierte en la primera plataforma en soportar la autenticación y firma digital en estos dispositivos!.

Disponible en App Store y Android Market cualquier país en Ingles, Frances y Español.

Una vez más, la plataforma amplía su Matriz de Compatibilidad, garantizando el principio de Neutralidad Tecnológica citada en la Ley 11/2007 de Acceso Electrónico de los Ciudadanos a los Servicios Públicos.

Formatos de firma  disponibles desde iPad/iPhone/Android:

  • XMLSignature
  • XAdES-BES
  • XAdES-EPES
  • XAdES-T
  • XAdES-C
  • XAdES-XL
  • XAdES-A
  • CMS (Cryptographic Message Syntax)
  • Facturae
  • PDF-Signature

APIs y módulos disponibles para la integración de terceros:

  • Java
  • .Net
  • Php
  • Pyton
  • Drupal
  • Joomla
  • Django

Para ofrecer servicios a estos dispositivos puedes puedes instalar Viafirma en tus instalaciones sobre:

  • Websphere
  • Weblogic
  • Tomcat 5, Tomcat 6
  • GlassFish v3

O si lo prefieres puedes utilizar directamente nuestro servicio “on demand” y ofrecer a tus clientes autenticación y firma digital de una forma muy sencilla y económica.

Autoridades de certificación soportadas por la plataforma:

  • Firma Profesional
  • Camerfirma (Cámara de Comercio)
  • Ancert (Agencia Notarial de Certificación)
  • Izenpe (Gobierno Vasco)
  • ACA (Autoridad de Certificación de la Abogacía)
  • ANF AC (Asociación Nacional de Fabricantes)
  • Avansi (primera CA autorizada en la República Dominicana)
  • Cámara de Comercio y Producción de Santo Domingo (República Dominicana)
  • Firma Digital (Sistema Nacional de Certificación Digital de Costa Rica)
  • SINPE (Sistema Interbancario de Negociación y Pago Electrónico) – Costa Rica
  • DNIe * no disponible para iPhone/iPad/Android
  • FNMT (Fábrica Nacional de Moneda y Timbre) * requiere convenio con la FNMT

Más información en bubiloop:Viafirma Mobile App

Artículos relacionados:

http://www.xnoccio.com//1247-firma-digital-movil-en-ipad_iphone_firma_electronica/

http://www.xnoccio.com//1201-android-y-mi-certificado-digital/

Hudson: Nuestro compañero

18 Jul 2010

Os dejamos las estadísticas de uso de nuestra herramienta de integración continua preferida!
Hace más de 2 años que usamos Hudson como herramienta en todos nuestros proyectos de desarrollo, y en poco tiempo pasó a convertirse en un pilar central de nuestro entorno de desarrollo.

Tras estos dos años, estos son los datos:

Proyectos gestionados (Jobs configurados)192
Proyectos en Activo:52 *(usados en los últimos 20 días)
Numero total de compilaciones realizadas6442
Despliegues automáticos al servidor de desarrollo4127 (sobre nuestros 5 entornos)
Media de operaciones diarias:12

La instalación es la por defecto sobre Linux, junto a un Slave que utilizamos puntualmente para las test sobre Windows.

Respecto a los plugins, aunque le hemos dado una oportunidad a practicamente todos, estos son los más utilizados:

  • SVNCopyPlugin (Plugin desarrollado internamente por Viavansi para la sincronización con el SVN del cliente tras despliegues exitosos)
  • Hudson SCP Publisher Plugin (desarrollado internamente para publicar en nuestro sistema de descargas )
  • ChuckNorris Plugin
  • SubversionTaggin Plugin
  • Disk Usage Plugin
  • Seleniumhq Plugin
  • Sonar Plugin
  • Dependency Analyzer
  • Backup Plugin
  • Deploy Plugin
  • SCP Plugin
  • Jabber Plugin

Algunos artículos relacionados:

Introducción a Hudson: http://www.xnoccio.com//362-hudson-parte-1-introduccion/Introducción al desarrollo de Plugins: http://www.xnoccio.com/?p=464Comparatíva: http://www.xnoccio.com//368-eligiendo-nuestro-entorno-de-integracion-continua-i/
y conclusiones http://www.xnoccio.com/?p=372

Android y mi certificado digital

30 Jun 2010

La nueva versión de Viafirma 3.0, proporciona como principal novedad el soporte para autenticación y firma digital desde dispositivos móviles como Android, iPhone o iPad.
De esta forma Viafirma se convierte en la primera plataforma de autenticación y firma digital con soporte completo para Android, iPhone o iPad.
A continuación vamos a mostraros un ejemplo de autenticación digital utilizando Viafirma desde Android.

En los próximos días iremos ofreciendo ejemplos de autenticación y firma desde los diferentes dispositivos móviles ya soportados.

¿Qué implica esto?

Pues que las entidades que opten por utilizar Viafirma podrán ofrecer servicios de autenticación y firma digital a sus usuarios móviles. Imagina por ejemplo acceder a tu banco mediante autenticación digital desde tu Android!

¿Cuándo estará disponible?

Ya está disponible para clientes corporativos y en unos días estará disponible en el Google Market de forma gratuita.

13-07-10

Disponibles ya los clientes para iPad y iPhone.

http://www.xnoccio.com//1247-firma-digital-movil-en-ipad_iphone_firma_electronica/

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 .

UsernameToken en Jax-ws (1/2)

04 Jun 2010

El objetivo de este artículo es mostrar como usar UsernameToken según la especificación Web Services Security UsernameToken Profile 1.0. El artículo consiera que el lector ya tiene experiencia en Jax-ws y se centra sólo en la configuración del mecanismo de seguridad para publicar y consumir servicios que requieran la identificación del solicitante con usuario y password haciendo uso de Jax-ws.

Dependencias requeridas

Aunque las dependencias necesarias están incluidas en algunos servidores de aplicaciones, si lo deseamos podemos o bien bajar la implementación de referencia directamente desde su web:

https://jax-ws-commons.dev.java.net y https://jax-ws.dev.java.net

O definir la dependencia en caso de que el proyecto sea Maven.

Definir  un nuevo manejador JAX-WS

En primer lugar indicaremos sobre la clase que implementa el WS el handlerchain.xml que define el manejador de seguridad  mediante la anotación @HandlerChain.


@HandlerChain(file = "handlerchain.xml")
@WebService(serviceName = "IcmsWSAPIService", targetNamespace = "http://www.juntadeandalucia.es/icms", name = "IcmsWSAPIClient", portName = "IcmsWSAPIPort", endpointInterface = "es.juntadeandalucia.icms.IcmsPublisherClient")
public class IcmsPublisherWSImpl implements IcmsPublisher {..}

A continuación indicaremos en el fichero handlerchain.xml el nombre de la clase que implementa en manejador de seguridad.

Implementar un manejador para WSS

Se necesitará una clase que implemente SOAPHandler que haciendo uso de XWSSProcessor se encargue de procesar los mensajes SOAP con los header WSSE. Un ejemplo de esta clase podría ser:


/**
* Web Services Security UsernameToken Profile 1.0
*
*/
public class SecurityHandler implements SOAPHandler<SOAPMessageContext> {

XWSSProcessor securityProcessor = null;

/**
* Build the Security Handler
*/
public SecurityHandler() {

try {
// Creamos el procesador SOAP para WSS
final InputStream input = this.getClass().getResourceAsStream("/user-pass-authenticate-server.xml");
final XWSSProcessorFactory factory = XWSSProcessorFactory.newInstance();
securityProcessor = factory.createProcessorForSecurityConfiguration(input, new SecurityEnvironmentHandler());
input.close();
} catch (final Exception e) {
logger.error("No se puede inicializar El Handler", e);
}

}

/**
*  Recuperamos el bloque header.
*/
public Set<QName> getHeaders() {
final QName securityHeader = new QName("http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-   secext-1.0.xsd", "Security", "wsse");
final HashSet<QName> headers = new HashSet<QName>();
headers.add(securityHeader);
return headers;
}

public boolean handleFault(final SOAPMessageContext messageContext) {
return true;
}

public boolean handleMessage(final SOAPMessageContext messageContext) {
final SOAPMessage message = messageContext.getMessage();

try {
// Contexto WSS
final ProcessingContext context = securityProcessor.createProcessingContext(message);
context.setSOAPMessage(message);
SOAPMessage verifiedMsg = null;
verifiedMsg = securityProcessor.verifyInboundMessage(context);

// Obtenemos el usuario y pass indicado en la request
String username = null;
String pass = null;
final Subject subject = SubjectAccessor.getRequesterSubject(context);

final Set<Principal> principals = subject.getPrincipals();
if (!principals.isEmpty()) {
final Principal principal = principals.iterator().next();
// Obtenemos en CN: CN=userName
username = StringUtils.substringAfterLast(principal.getName(), "=");
}
final Set<Object> publicCredentials = subject.getPublicCredentials();
if (!publicCredentials.isEmpty()) {
pass = (String) publicCredentials.iterator().next();
}

// Verificamos el comportamiento user y pass
validateUser(username, pass);

messageContext.setMessage(verifiedMsg);
} catch (final XWSSecurityException e) {
logger.error("WSS validation problem. ", e);
throw SecurableSoapMessage.newSOAPFaultException("WS validation problem.", e);
}

return true;
}

/** Validación específica de la aplicación.
* @param username
* @param pass
* @throws XWSSecurityException
*/
private void validateUser(final String username, final String pass) throws XWSSecurityException {
// Verificación específica de la aplicación.
//throw new XWSSecurityException("Invalid user." + username);

}

public void close(final MessageContext messageContext) {
}

private static Logger logger = Logger.getLogger(SecurityHandler.class);

}

Esta clase será la encargada de procesar todos los mensajes, verificando que todos son válidos y contienen un usuario y pass correcto. Un ejemplo de un mensaje válido WSS sería:


<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"       S:mustUnderstand="1">
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1255949753848350309586">
<wsse:Username>usuario</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">****</wsse:Password>
<wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">9w+YwOatF9l1/otioQ75d5Yr</wsse:Nonce>
<wsu:Created>2009-10-19T10:55:54.418Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</S:Header>
<S:Body>
<ns2:ping xmlns:ns2="http://www.juntadeandalucia.es/icms" xmlns:ns3="http://www.juntadeandalucia.es/icms/data">
<ns2:request>test</ns2:request>
</ns2:ping>
</S:Body>
</S:Envelope>

Próximamente cómo crear un cliente Jax-ws que consuma servicios securizados con   UsernameToken.

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.