sábado, 14 de diciembre de 2013

ESB de WSO2 y Transacciones.

El ESB de WSO2 es un buen ESB pero a veces es  frustante la falta de documentación apropiada en determinados temas como pueden ser las transacciones.

En su documentación en línea podemos ver el mediador transaction.
Y en el ejemplo que usan siempre lo ponen de conjunto con el mediador dbreport en operaciones CRUD sobre bases de datos.

La realidad es que los usuarios de este ESB buscan mucho más que eso y  se puede evidenciar cuando vemos las preguntas hechas en SO. Algunas de las cuales son:

  1. How to Manage Transaction across sequences in WSO2 ESB
  2. WSO2 ESB Distributed Transations
  3. In WSO2 ESB 4.7.0 can we do JMS rollback in receiving sequence?
Y ahora acabo de encontrar esta otra.

Entre mis preocupaciones están las siguientes:

  1. Se puede usar el mediador transaction con cualquier otro mediador? Esto no queda claro en la documentación.
  2. Se puede usar el mediador transaction para acciones realizadas en varias secuencias? En las respuestas dadas en SO tal parece que no, pero esta información no aparece en la documentación oficial del ESB de WSO2.
  3. En vez de seguir poniendo siempre el mismo ejemplo de uso del mediador en cada nueva versión de la documentación del ESB, por qué no incluir nuevos ejemplos que respondan a las preguntas hechas por la comunidad de desarrollo de WSO2 en StackOverflow?
Al final terminé posteando una pregunta en SO con algunas de estas preocupaciones.

Introducción al ESB de WSO2 a través de ejemplos prácticos. III



Para darle continuidad a la serie de introducción al ESB:

En esta entrada veiamos como se podía solucionar un problema a través del ESB de WSO2.

Luego en la segunda entrada  veíamos como se podía implementar un servicio proxy en el ESB para darle solución al problema planteado en la primera parte, e incorporar elementos de seguridad y prueba usando el SOAPUI.
 
En esta tercera entrada quisiera compartir con ustedes una forma muy útil de agregar seguridad de grano fino a nuestros servicios y aplicaciones web con la ayuda del WSO2 ESB y el WSO2 IS.

Ahora solo presentaré un diseño de alto nivel, en otra entrada veremos su implementación.

La idea parte de definir una arquitectura de seguridad para una organización que se va moviendo hacia un entorno orientado a servicios, donde deben coexistir aplicaciones legadas y  compuestas, así como servicios web y restful, y todo debe estar protegido por políticas de seguridad a diferentes niveles de granularidad.


La arquitectura genérica puede ser la siguiente:


Todos los accesos se realizarían a través del ESB de WSO2 el cual controlaría con la ayuda del WSO2 IS quien tiene acceso o no a los servicios.
Para lograr esto se dispone de un repositorio de políticas de autorización y de un almacén de credenciales.
 
El cómo interactúan el ESB y el IS de WSO2 se ve en la siguiente imagen.



De esta manera la seguridad se puede definir a nivel de políticas, no solo de roles, con un nivel tan detallado como se desee, esto se logra gracias a la arquitectura XCML que implementa el IS de WSO2

En otra entrada estaremos viendo cómo se implementa esta solución en el ESB+IS de WSO2.

martes, 10 de diciembre de 2013

WSO2 y el monitoreo de aplicaciones web en Java.


La suite de WSO2 tiene cosas para casi todo, y en esta entrada quisiera compartir con ustedes una de las que más utilidad queremos sacar. El monitoreo de aplicaciones web.

La idea es que buscamos saber de las aplicaciones web la siguiente información:

  • Cantidad de solicitudes de acceso, respuesta e intentos fallidos.
  • Promedio del tiempo de respuesta de la aplicación web.
  • Tiempos mínimos y máximos de respuesta.
  • Cantidad de visitas de usuarios.
  • Tiempo promedio de estancia de los usuarios en la aplicación web.

Para lograr esto basta con seguir los pasos explicados en el siguiente tutorial [1] y podrán monitorear todo lo anterior. A continuación les dejo algunas pantallas para que puedan ver.




Enlaces:


viernes, 6 de diciembre de 2013

WSO2 Identity Server. Otro caso de éxito más.

Estaba revisando un nuevo caso de éxito de WSO2 relacionado con el tema de la seguridad y como una imagen vale más que mil palabras aquí les dejo la siguiente:


Se trata de un proyecto desarrollado en Arabia Saudita, para gestionar diferentes programas relacionados con la seguridad social y programas de asistencia para personas sin empleo, los cuales permitan que se entren solicitudes de trabajo y se gestionen diferentes tipos de pagos.

El tema en cuestión es que este proyecto inició con un solo programa, luego al incorporársele nuevos programas identificaron  la necesidad de un mecanismo de gestión de las identidades para todos los involucrados en los programas, y de un mecanismo de  autenticación centralizado que implementara el Single Sign On, o la autenticación única, la cual permite que una vez autenticado en un sistema ya no tengas que autenticarte nuevamente en los otros sistemas asociados al mismo dominio de seguridad, lo cual facilita a los usuarios la gestion de sus credenciales ya que solo necesitan una para todos los sistemas y no una para cada uno de ellos.

Nos comentan que la primera decisión arquitectónica tomada fue escoger entre los diferentes proveedores de sistemas para implementar SSO y al final se decantaron por el WSO2 Identity Server. La segunda decisión fue escoger entre OpenID y SAML, seleccionando finalmente a OpenID.

La implementación de la solución llevó 2 meses y el resultado final el siguiente:


Un clúster de 5 instancias del WSO2 Identity Server que permiten manejar 2000 peticiones de autenticación por segundo, con 4 millones de usuarios. Claro que eso no es todo, así que los invito a ver el pdf original.

Pueden ver el artículo en [1].