WSO2: en ocasiones veo “huesos”.

De un tiempo a esta parte parece que están bastante de moda los productos de WSO2 (hueso para los amigos). Hay algunos compañeros que se están certificando en los diferentes productos de esta plataforma, bastantes empresas que están empezando a implantar algunos de ellos.

Desde ya podemos encontrar también abundante información en la web, artículos divulgativos o tutoriales... sobre cómo hacer esto o lo otro con alguno de los productos de la plataforma WSO2.

Entonces, algunos os estaréis preguntando, si hay tanta información y movimiento, ¿por qué escribir un artículo más sobre las bondades o entresijos de esta tecnología? ¿No está todo dicho ya?

Pues bien, la respuesta es que, a pesar de todo esto, creo que aún puede resultar algo lioso hacerse una idea general de qué supone esta plataforma o cómo nuestras empresas se pueden beneficiar de ella.

Para intentar capturar esa "foto general" de la plataforma en unos pocos párrafos, voy a explicar los conceptos claves resumiendo, en unas pocas ‘pregunta/respuesta’, las muchas conversaciones vividas en los últimos tiempos con algunos de nuestros clientes… ¡espero que os sea útil!

Pregunta - Está bien, ¿alguien me puede explicar qué es esto de hueso (WSO2)?

Respuesta - Sí, claro, WSO2 es una plataforma tecnológica compuesta por una familia de productos OpenSource, licenciados bajo Apache License 2.0, independientes entre sí, pero fácilmente integrables entre ellos, que solucionan algunos de los casos de negocio típicos en la transformación digital de las empresas.

P - Si es OpenSource y Apache 2.0, ¿significa que lo puedo utilizar a mi antojo?

R - Eso es, significa que tienes acceso al código fuente de los productos y que lo puedes utilizar comercialmente en cualquiera de los proyectos de tu empresa.

P - ¿Y cuáles son estos productos? ¿Para qué sirven?

R - En Paradigma tenemos experiencia con algunos de ellos. Por ejemplo, el más famoso, y con el que hemos trabajado bastante, es su producto de API Management.

P - ¿API Management? No sé yo si me preocupa mucho este tema...

R - Bueno, el concepto de API Management, y todo lo que conlleva, es un pilar fundamental dentro del proceso de transformación digital de cualquier compañía. En Paradigma ya hemos publicado algún que otro artículo sobre este tema, que creo que te puede resultar de utilidad.

De hecho, hay otros muchos productos de API Management en el mercado que son bastante interesantes también: ApiGee (desde hace poco tiempo también en Google Cloud Platform); 3Scale, de RedHat; o API Connect, de IBM son otras posibilidades de implementación.

P - Entonces, ¿por qué apostar por esta solución?

R - Bueno, aunque las otras posibilidades son muy válidas también, en Paradigma siempre nos ha parecido interesante explorar las soluciones OpenSource. Además, el conjunto de funcionalidades que soporta esta herramienta no está nada mal y, además, su fácil integración con otros módulos de WSO2 hace que su posibilidades aumenten considerablemente.

P - ¿Qué cubre esta herramienta exactamente?

R - Es una solución completa de API Management. Básicamente te ofrece tres cosas fundamentales:

Primero, disponer de una herramienta gráfica de creación y publicación de API’s. En esta herramienta podemos configurar el nivel de seguridad, o control de acceso, que deseemos para los endpoints de nuestras API’s, establecer límites de consumo, aplicar posibles planes de suscripción de nuestras API’s con fines monetarios, versionarlas, etc.

Además, en esta herramienta podemos aplicar metodologías ágiles de trabajo, como API First, mediante el concepto de prototyped API’s que nos ofrece la propia herramienta.

Segundo, disponer de un portal colaborativo donde los creadores de API’s puedan publicar sus API’s, y los potenciales suscriptores puedan consultarlas, probarlas, puntuarlas, comentarlas en un foro con otros usuarios, etc.

Y, por último, disponer de un portal de administración donde gestionar los usuarios o diversos aspectos generales de la plataforma.

P - No está mal, ¿lo podría instalar en mis propios servidores?

R - Sí, aunque también tiene una solución en cloud, admite la instalación on Premise, ideal para la ‘apificación*’* de los servicios que tengas desplegados dentro de tu red corporativa.

P - ¿Estas instalaciones admiten la alta disponibilidad?

R - Claro, podemos conseguirla de diversas formas. Podemos realizar una instalación unificada del producto o distribuida de cada una de sus piezas (Publisher, Store, Traffic Manager, Gateway, Key Manager), siguiendo uno de los múltiples patrones de despliegue que nos ofrece. También podemos elegir entre utilizar contenedores (Docker) o no, pero, en cualquiera de los casos, y con la ayuda de Nginx, podemos realizar despliegues en alta disponibilidad del producto.

P - Y para que mis aplicaciones corporativas puedan consumir los servicios expuestos en esta herramienta... ¿cómo lo hago?

R - Tiene varias opciones, mediante el protocolo OAuth2 o alguno de las otras opciones adicionales que te ofrece la herramienta. Para ello, lo que tenemos que hacer es registrar nuestra aplicación web en la herramienta de API Manager, activar los flujos de autenticación que prefiramos para nuestra aplicación y suscribirla a las API’s que queramos consumir.

En el paso de registro de la aplicación, la plataforma nos proporcionará una clave pública y otra privada (secret) para nuestra aplicación corporativa. Estas claves son las que nuestra aplicación web corporativa tendrá que utilizar para autenticarse y poder invocar a los endpoints de las API’s que se haya suscrito.

P - Espera, espera… ¿qué es eso de OAuth2 y cómo lo hago exactamente?

R - OAuth2 es un protocolo de autorización bastante extendido actualmente. Básicamente, sintetizando bastante la idea, y aunque existen matices entre los distintos flujos (grants) del protocolo, lo que podemos conseguir es que nuestra aplicación corporativa (client) pueda consumir las API’s publicadas en el API Manager (resources) en nombre del usuario (resource owner) que está accediendo a la propia aplicación corporativa.

El esquema general es que la aplicación corporativa debe realizar una solicitud de generación de token de acceso (access token), indicando los parámetros necesarios (claves públicas/privadas, grant utilizado, etc.), para luego utilizar este token de acceso (access token) en cada una de las llamadas a realizar a los endpoints del API publicado en el API Manager.

P - Vale, eso que has mencionado de grants o flujos, ¿me podrías explicar un poco a qué te estás refiriendo exactamente?

R - Sí, cada flujo, o grant, está pensado para abordar la problemática general atendiendo a unos casos determinados de uso. Los grants que disponemos son los siguientes:

• Client Credentials: Comunicación directa entre app - endpoint. No existe el usuario final dueño (resource owner) del endpoint (resource), sino que la aplicación corporativa (client) puede consumir el endpoint (resource) utilizando solo sus claves pública y privada (recuerda que estas claves son las que obtenemos al registrar la aplicación en el API Manager). Este flujo es ideal para aquellas invocaciones a endpoints que no necesitamos a un usuario final concreto. Por ejemplo, la invocación a un endpoint que te devuelva la previsión meteorológica de una ciudad.
• Resource Owner: El usuario final confía plenamente en la aplicación corporativa, de modo que ésta utiliza directamente sus credenciales (usuario/password) para acceder al endpoint (resource).
• Implicit: La aplicación, mediante la autorización del usuario final, puede acceder al endpoint (resource) haciendo uso solamente de su clave pública (la que obtenemos al registrarla en el API Manager). Este flujo es el que suelen utilizar las aplicaciones móviles y las aplicaciones web que no tienen capacidad para almacenar su clave privada (secret) de forma segura.
• Authentication Code: Similar al anterior, pero más seguro, ya que, además de la autorización del usuario final y la clave pública, la aplicación (client) necesita su clave privada (secret) en un segundo paso adicional de autenticación. Este flujo es el más seguro y es que usa el resto de las aplicaciones webs, que sí pueden almacenar su clave privada (secret).

P - ¿Y cómo controlo que unos usuarios puedan acceder a ciertas API’s y otros a otras API’s diferentes?

R - Para eso el protocolo introduce los conceptos de roles y scopes. Un rol es lo que le asignamos a un usuario para darle cierta característica: rol cliente, rol administrador, etc. Y un scope es una bolsa lógica de estos roles, con un nombre, y asignable a los diferentes endpoints (API’s, resources) publicados en el API Manager. Los scopes van asociados a los tokens de acceso (access tokens), de modo que dependiendo de los scopes asignados a un determinado token, éste podrá consumir más o menos endpoints (recursos) de las API’s publicadas en API Manager.

Por ejemplo, podemos hacer que en el API */*store, que tiene dos endpoints, uno para ver artículos y otro para eliminar artículos, el endpoint para ver artículos sólo pueda ser consumido mediante tokens con el scope read, y el segundo (eliminar artículos) mediante tokens con el scope manage.

A su vez, podemos configurar que el scope read lo pueda adquirir (generar en su access token) cualquier usuario con los roles user y admin, mientras que el scope manage sólo pueda ser adquirido (generado en su access token) por usuarios con el rol admin.

De esta forma estamos consiguiendo que los usuarios ‘user*’* solo pueda ver los productos y los usuarios ‘admin’ puedan verlos y eliminarlos. Gráficamente sería algo así:

• Endpoint Ver artículos (/store/articles/read/) -> Scope Read
• Endpoint Eliminar artículos (/store/articles/remove/{id}) -> Scope Manage
• Scope Read -> Rol Admin, Rol User.
• Scope Manage -> Rol Admin.

P - Vale, más o menos lo entiendo. Pero, una cosa, toda esta gestión de tokens… entonces el API Manager dispone de su propia pieza de generador/validador de tokens, ¿verdad?

R - Sí, eso es. De hecho, WSO2 API Manager tiene esta funcionalidad totalmente desacoplada dentro de su infraestructura mediante la pieza Key Manager. Esto, que puede resultar baladí en un primer momento, es algo bastante ventajoso, ya que podemos configurar nuestro propio proveedor OAuth, o bien, utilizar WSO2 Identity Server como tal.

P - Vale, bien, ya veo que ya me estás hablando de otro producto. ¿Qué es eso de Identity Server?

R - WSO2 Identity Server es un gestor de identidades. Sirve para gestionar de manera unificada toda la gestión de usuarios, permisos, etc., que normalmente lidiamos en las aplicaciones de negocio corporativas.

P - Pero yo ya tengo mis usuarios registrados en mi propio sistema, no los quiero tener duplicados por tener una nueva tecnología...

R - Claro, no tienes porqué duplicarlos. Mediante esta herramienta podemos configurar como repositorio o fuentes de usuarios (user store) lo que ya tengamos en nuestra empresa, ya sea una BBDD relacional o un LDAP, por ejemplo.

Sólo tenemos que integrarlos mediante la opciones de configuración que nos ofrece la propia herramienta. Además, en el caso de que lo consideremos interesante, también podríamos delegar la fase de autenticación en otros sistemas federados de autenticación, como son Google, Yahoo, Twitter o cualquier otro proveedor de identidad con el que ya estemos trabajando.

P - Muy bien, ¿pero esto qué me aporta?

R - Pues por ejemplo, podrías delegar todas las operaciones de login de las aplicaciones corporativas a esta herramienta, evitando repetir este trabajo de desarrollo en cada una de ellas.

Además, con esto tendrías unificado todos los usuarios de tus aplicaciones corporativas en un solo sitio, facilitando así su mantenimiento. Y, por si fuera poco, también te facilita la implementación de un sistema de SSO (Single Sign On) entre tus aplicaciones corporativas, vía SAML2 o OpenId Connect.

P - Está bien, aunque no veo muy bien la conexión de Identity Server con API Manager…

R - Bueno, además de la toda la centralización de usuarios y seguridad que acabo de explicar, nos aporta dos cosas más: que las aplicaciones corporativas puedan generar el token de acceso (access token) de OAuth2 utilizando el token que ya tienen (por ejemplo, el SAML2), para poder invocar las API’s del API Manager; y que podamos establecer un grano más fino de autorización para nuestras API’s.

P - ¿Cómo que un grano más fino?

R - Identity Server nos ofrece la posibilidad de generar políticas de acceso mediante reglas más elaboradas, basadas en el estándar XACML. Esta característica, además de poderla utilizar de forma independiente, también la podemos aplicar en las comprobaciones de autorización en las invocaciones a las API’s del API Manager (vía mediadores o mediators), como escalón adicional de control de acceso al procedimiento que ya comentaba antes de roles y scopes.

P - Vale, de acuerdo, ¿y qué me dices de la posibilidad de monitorizar y tracear todo esto? Me da un poco de miedo delegar toda esta responsabilidad en estos productos.

R - Recuerda que tanto el API Manager como Identity Server se pueden configurar en Alta Disponibilidad (HA), por lo que no deberías tener ningún problema. Y en cuanto a la monitorización, además de las posibilidades ‘de caja’ que nos ofrece API Manager, también podemos utilizar Data Analytics Server, e integrarlo con estas dos soluciones.

P - Ya me estás hablando de otra cosa, ¿qué es eso de Data Analytics Server?

R - Data Analytics Server (DAS) es un producto de WSO2 que permite la recogida, análisis y presentación de datos. Como te comentaba, mediante este producto puedes monitorizar fácilmente la actividad de API Manager e Identity Server.

Por ejemplo, en cuanto al API Manager, puedes saber cuántos suscriptores a las API’s existen, el consumo de estas API’s, cuánto tardan en responder, qué tiempo tarda el servicio de backend invocado, etc.

Y en cuanto al Identity Server, puedes consultar toda la información relacionada con la creación de sesiones por parte de los usuarios, generación de tokens de acceso, etc. Además, también es bastante útil el sistema de alertas que tiene. Por ejemplo, podemos configurar el envío de correos a una determinada cuenta de correo cuando se detecte el mal funcionamiento de una de las API’s publicadas.

P - Y todos estos datos que me comentas, ¿cómo los visualizo?

R - La propia plataforma dispone de un conjunto de paneles (dashboards) para mostrarte toda esta información. Además, no olvides que todo esto es lo que tienes ‘de caja’ con DAS en la integración con API Manager e Identity Server, pero DAS, al igual que el resto de productos de WSO2, lo puedes utilizar de forma independiente.

P - ¿A qué te refieres? ¿Lo puedo utilizar para analizar el uso de otras cosas?

R - Eso es. Con esta herramienta podrías analizar las estadísticas de uso de otras aplicaciones corporativas que ya tengas o vayas a implementar. Para ello, éstas tienen que publicar el flujo de eventos que describan su uso y/o su comportamiento.

Luego, el funcionamiento del DAS es análogo a lo que realiza con las otras herramientas de WSO2 (API Manager e Identity Server) que te comentaba: el flujo de eventos publicado por tu aplicación es ingestado por el DAS, procesado mediante trabajos *batch **(*ejecutados periódicamente tras un periodo configurable de tiempo, ej: 5 minutos), y publicados donde nos resulte más útil.

Es decir, con los resultados de estos análisis podemos construir nuestros propios paneles (dashboards) de visualización, generar envíos de correos, integrar con otras piezas de arquitecturas, como topics o colas de mensajería (AMQP, JMS, MQTT), hacer llamadas HTTP, etc.

P - Interesante... ¿Hay algún caso de uso más para el que pueda utilizar alguno de los productos de WSO2?

R - La verdad es que sí. Por ejemplo, otro de los productos con el que estamos trabajando en Paradigma es con el Enterprise Integrator, y más concretamente con los perfiles de ESB y Analíticas.

Esta pieza te permite integrar los diferentes procesos de negocio que puedan existir entre diferentes servicios o departamentos de tu compañía de una manera gráfica y centralizada. La idea principal de este producto es integrar mediante la implementación de los patrones de integración empresariales, Enterprise Integration Patterns (EIP), como hacen otros productos ESB, como Mule o Tibco, o frameworks de desarrollo, como Spring Integration o Apache Camel.

Además, los nuevos procesos ESB que publiquen un endpoint HTTP, al igual que cualquier endpoint HTTP de cualquier otro servicio, son fácilmente publicables (‘apificable’) en API Manager, beneficiándose de todo el ecosistema y funcionalidades que te he ido comentando anteriormente.

P - Y todo esto que me has contado, ¿es tan bonito como parece?

R - Como te digo, se trata de una plataforma OpenSource y Apache 2.0, así que sólo por eso puede merecer la pena darle una oportunidad. En mi opinión, tienen ciertas cosas que mejorar, como su documentación o ciertos errores en algunos de sus módulos... en Paradigma hemos realizado varios proyectos con estas tecnologías y han resultado bastante satisfactorios.

Así que, puede que no sea todo tan bonito, pero creo que es una opción muy a tener en cuenta para resolver las casuísticas que hemos ido comentando durante nuestra charla, sin duda.

P - Vale, creo que ya he procesado suficiente información por hoy…

R - Sí, estoy de acuerdo, creo que ya te puedes hacer una idea general del ecosistema de WSO2, y de lo que éste te puede ofrecer… aunque aún no hemos hablado de su módulo de IoT, pero como dices, está bien por hoy.

P - Sí, sí, creo que después de esto puede que yo también empiece a ver ‘huesos’ de vez en cuando…

R - ¡Eso espero! Pero, de todas formas, si hay algo que no te ha quedado claro, y quieres que profundicemos, no dudes en contactarnos de nuevo.