G6Flow ® Introducción al Xposer Server

Objetivos de la sesión

En la siguiente sección, se plantea cubrir los siguientes objetivos de estudio.

1. Conocer el componente.
2. Entender los motivadores para su creación
3. Conocer como evoluciono
4. Conocer sus capacidades
5. Conocer la relación entre estos componentes.
6. Conocer los artefactos a alto nivel

Que es el Xposer Server

El siguiente listado puede describir perfectamente lo que es el Xposer Server:

• Es un servidor encargado de enrutar peticiones REST, hacia un backend.
• Utiliza un mecanismo de reglas, para encaminar hacia un endpoint , basado en identificación del consumidor.
• Unifica la comunicación hacia diversos endpoints
• Sirve como punto de refuerzo de seguridad
• Homologa los puntos críticos de seguridad al consumo
• Ofrece un punto de identificación del consumidor y aplicación de estrategias Zero Trust (OAuth2 y Open Id Connect ).

Principales motivadores.

A continuación, se listan los principales motivadores, para la creación de este componente.

• Adaptación y transformación de peticiones y respuestas, para funcionamiento entre tecnologías diferentes.
• Enriquecimiento de las solicitudes a nivel de headers , para agregar identificadores de peticiones y headers de seguridad.
• Unificar y estandarizar la capa de seguridad para todos los servicios de la organización
• Contar con un punto de control que abarque la mayoría de los elementos de OWASP Top 10, para garantizar la seguridad y protección de la información.
• Contar con un componente que automatice la generación de API Docs. para ser compartidos.
• Contar con un punto de recolección de auditoria para ser reenviado en paralelo a las peticiones.
• Contar con una baja huella digital y ejecutarse en tecnologías modernas y optimizadas energética y procedural mente.

Principales características

Debido a los motivadores anteriores, comenzamos a trabajar para lograr convertirlas en un producto que puede ayudar a las organizaciones a aterrizar inmediatamente en estrategias de API, sin necesidad de contar con infraestructura dedicada de alto volumen, y debido a esto, podemos hablar de una democratización de la tecnología de API, teniendo en cuenta, que este componente, ayuda a simplificar costos y operaciones, teniendo en cuenta siempre el rendimiento y la disponibilidad de los servicios. Las principales características se listan a continuación:

• Centralización de las comunicaciones desde los consumos exteriores, hacia los servicios internos de BEI.
• Habilitación de los elementos de seguridad necesarios para exponer servicios REST a nivel de protocolo HTTP.
• Habilitación de gobierno a través de la aplicación de reglas y rutas, mediante la interface de administración.
• Activación de auditoria completa de las transacciones para pasarlas al componente de recolección de esta.
• Incorporación de metadatos configurables para ser aplicados mediante las rutas del Xposer.
• Contar con una huella tecnológica pequeña.
• Ser independiente y poder ejecutarse "todo en uno", sin necesidad de una base de datos externa.
• Aplicar configuraciones rápidas para prevenir caídas o programación de cambios demasiado complejas.

Evolución del componente

Al principio, el objetivo del Xposer, era la de habilitar proyectos de migración de tecnologías de API Management, de un fabricante a otro; conservando los estándares usados actualmente por la tecnología origen, cambiando progresivamente hacia la tecnología destino, con lo que hablábamos de Xposer como un "servicio de ocaso" tecnológico.

Eventualmente, y al ver la rapidez con la que podíamos lograr habilitar sets de api completos, controlando la mayoría de los elementos de las nuevas tecnologías; decidimos llevar a otro nivel este componente, y lo convertimos en una compuerta, que ayudo a habilitar las capas de integración que generamos mediante los BEIs.

Así también, al observar la resistencia que lográbamos obtener al realizar ejercicios de ataque y penetración de sistemas, y ver que podíamos corregir en un solo punto las vulnerabilidades, sin afectar debido a los cambios a los demás sistemas, convertimos este componente en el punto centrar de la capa de exposición de las integraciones.

Conforme hemos progresado, hemos agregado características adicionales, como la generación de servicios Mockups , para habilitar pruebas, composición de servicios e integración con servicios estándar de Oauth2 y Open ID Connect .

Esta componente se encuentra en una evolución continua, y debemos estar atentos a los cambios que se van aplicando conforme va adquiriendo madurez.

Arquitectura y componentes.

A continuación, se muestra un diagrama de los componentes del Xposer, y en esta sección se explicarán los archivos de configuración que utiliza para su operación.

Internamente, el Xposer cuenta con diferentes funciones, que, en conjunto, permiten la exposición de los servicios previamente creados mediante el uso de BEIs, o por servicios REST debidamente formados.

Como parte de sus funciones este cuenta con:

• API & API Docs. Services . Esta capa permite exponer de manera estandarizada, los servicios REST configurados dentro del servicio. Al igual que BEI, este funciona a partir de JSON Schemas , para habilitar documentación y validaciones específicas de los servicios. Además , en este punto se inyectan elementos como el Identificador de la transacción para ayudar a generar una trazabilidad en la auditoria, y headers personalizados para su registro y reenvío hacia el backend de servicios.

• Oauth Evaluator . Este servicio se comunica con un Servidor de Autorización soportado, para poder reenviar los tokens y verificar su valides y el scoping de dichos tokens. Actualmente se sugiere el uso de Keycloak como Identity y Access Provider, el cual también puede ser expuesto mediante el mismo Xposer.

• Rules Evaluation Motor. Este componente, ayuda a l eer la configuración de los servicios, la cual es habilitada mediante el uso de reglas establecidas en archivos de configuración Json , y que pueden ser transportadas hacia otros Xposer servers, para aumentar capacidades o replicar ambientes de manera rápida.

• Internal Proxy Service. Se encarga de reenviar las peticiones, de acuerdo a las reglas, hacia los servidores configurados para este propósito.

• Mocking services . Este componente, ayuda a habilitar servicios de prueba, sin necesidad de infraestructura dedicada, y solamente simulando las peticiones. Es posible agregar reglas para identificar y darle un poco de inteligencia a estos sets, pero la idea es acelerar la muestra de los servicios para que puedan correr otros ciclos de desarrollo que dependan de las APIs, aun sin que estas existan.

Form factors

Este componente se encuentra disponible en formato de contenedor, sin embargo, también se puede contar con una imagen compatible con arquitecturas Intel y AMD, así como ARM, lo que hace que el componente pueda ser desplegado en sistemas de alto rendimiento eléctrico y de procesamiento.

Interacción entre los componentes.

Aunque el Xposer Server puede operar de manera independiente, existen componentes que ayudan a mejorar la experiencia de uso y a agregar funciones de recolección de auditoria completa, utilizando simplemente algunos flags de configuración.

A continuación, se muestra un diagrama, para conocer como es que sucede la interacción entre los componentes que utiliza el Xposer.

En el diagrama se puede apreciar, que Xposer Server trabaja para ofrecer una capa de consumo de servicios, sin permitir el acceso directo hacia el Backend , reforzando en el camino la seguridad mediante el uso del servidor de Autenticación y Autorización, y además de todo, teniendo la capacidad de solicitar certificados digitales válidos, para agregar MTLS a las solicitudes de información hacia el componente.

Sistema de configuración

Para lograr orquestar el aseguramiento y encaminamiento de las peticiones mediante el Xposer, existen algunos artefactos que requiere Xposer para poder habilitar las rutas y permitir a los consumidores llegar hacia los servicios que su nivel de acceso les concede. Estos componentes se almacenan en la carpeta "data" del Xposer, donde son leídos y aplicados al momento de ser activado el servicio de Xposer.

Estos componentes, se listan a continuación.

• Routes
• Servers
• Mockups
• Objects
• Rules
• Apikeys
• Consumers
• Groups
• Clients

Cada uno de estos componentes, almacena una parte de la configuración que, mediante la declaración de las reglas, tiene un comportamiento específico, de acuerdo a la identificación del consumidor.

El siguiente diagrama muestra la relación entre los componentes, para lograr una mejor comprehensión de sus roles de uso en el Xposer.

Como se puede observar en el gráfico, el eje principal de la configuración son el sistema de reglas que usa el Xposer, el cual unifica quien puede realizar los consumos, mediante qué tipo de identificación ( Apikeys , token Oauth, certificado digital), hacía que "server" o "mockup" se realiza el enrutado de la petición y la ruta a la que se aplica la regla. Esto ayuda a agregar una lógica de consumo, que puede ser útil para segmentar las cargas de consumo hacia el backend de servicios, e inclusive, desviar las llamadas hacia otras infraestructuras visibles desde el Xposer; manteniendo la transparencia hacia el consumidor.

Además, se cuenta con configuración mediante variables de entorno, para poder habilitar cosas como el certificado SSL para habilitar HTTPS mediante TLS para el consumo de los servicios, el nivel de logging , duración del cache etc. Los aspectos de configuración serán abarcados en las secciones posteriores de este entrenamiento.

Descripción de los componentes de configuración

A continuación, se da una mirada mas detallada de las responsabilidades de cada uno de los artefactos de configuración necesarios para la habilitación de rutas desde el Xposer.

Route

En este archivo, se guarda un arreglo con la definición de las rutas, al estilo del BEI. Utiliza JSON Schema para la definición de las rutas, sus partes de la petición ( body , query, params , headers ) las posibles respuestas y la descripción de cada uno de las secciones.

Mientras mas detalle se agregue, los detalles de la documentación serán mejores y mas entendibles por parte de los desarrolladores que los consumirán.

{
  "id": "string",
  "url": "string",
  "prefix": "string",
  "name": "string",
  "tags": ["string"],
  "enabled": "boolean",
  "methods": {
    "GET": {},
    "POST": {},
    "PUT": {},
    "DELETE": {},
    "PATCH": {},
    "HEAD": {}
  }
}

Objects

Se utilizan para definir y reutilizar estructuras entre servicios y para reducir el mantenimiento en cuanto surge la necesidad de modificar una estructura dentro de un servicio. Estos están relacionados directamente a los objetos que se configuran en la capa de BEI, y pueden ser compartidos entre estos dos componentes para evitar redundancia y repetición de definiciones.

{
  "id": "string",
  "name": "string",
  "description": "string",
  "properties": {
    "prop": {
      "type": "string|boolean|numeric|null|object|array",
      "description": "string"
    }
  }
}

Server

Se trata de la configuración de un destino existente, particularmente, aquí se registran los BEIs previamente configurados, y que sirven de destino a las peticiones que se realicen, mediante la identificación desde las reglas.

{
  "id": "string",
  "name": "string",
  "url": "string",
  "description": "string",
  "apikey": "string"
}

Mockup

Se trata de una definición corta, donde podemos agregar un conjunto de reglas, y una respuesta que obedezca al cumplimiento de estas condiciones, para regresar una respuesta programada según sea el caso, sin la necesidad de utilizar un servicio de backend existente.

{
  "id": "string",
  "name": "string",
  "description": "string",
  "cases": [
    {
      "name": "string",
      "method": "string",
      "rules": [
        {
          "messagePart": "string",
          "property": "string",
          "operator": "string",
          "value": "string"
        }
      ]
    }
  ]
}

Consumer

Este artefacto se encarga d e la configuración de certificados digitales para ser aceptados en caso de haber habilitado el uso de MTLS como uno de los mecanismos de identificación del consumidor, para permitir la comunicación con el Xposer.

{
  "id": " string ",
  "cn": " string ",
  "description": " string ",
  "publickey": " string ",
  "serialNumber": "string",
  "memberOf": ["string"],
  "enabled": "true"
}

Apikey

Este objeto, se utiliza para registrar un APIKEY que puede ser reemplazado fácilmente en caso de haber sido comprometido de alguna forma, sin necesidad de realizar cambios de configuración de manera drástica.

{
  "id": "string",
  "name": "string",
  "apikey": "string",
  "description": "string",
  "enabled": "boolean",
  "quota": "numeric",
  "quotaInterval": "h|d|w|m"
}

Client

Se utiliza para registrar los clientes autorizados que se encuentran definidos en el Authorization Server, y sirven para enriquecer las reglas, y realizar la propia identificación del consumidor, si es que esta habilitada la regla para ser consumido el servicio mediante token Oauth.

{
  "id": "string",
  "name": "string",
  "clientId": "string",
  "description": "string",
  "enabled": "boolean",
  "scopes": "string",
  "quota": "numeric",
  "quotaInterval": " h|d|w|m "
}

Group

Este objeto, sirve para agrupar consumidores, apikeys y clientes, para ser asignados a las reglas y simplificar la gestión de permisos, agregando una capa de concentración de permisos basada en grupos.

{
  "id": "string",
  "description": "string",
  "members": ["string"],
  "enabled": "boolean"
}

Rule

Este objeto, unifica los tipos de permisos; los consumidores, apikeys, clientes y grupos; los servicios y los mockups; referentes a las rutas que se expondrán mediante el Xposer. Se puede hablar de estos, como el pegamento del flujo de consumo y consumidores de los servicios del Xposer.

{
  "id": "string",
  "name": "string",
  "description": "string",
  "xposer": "string",
  "endpointType": "string",
  "mockup": "string",
  "server": "string",
  "composition": "string",
  "groups": ["string"],
  "consumers": ["string"],
  "clients": ["string"],
  "apikeys": ["string"],
  "authorizationType": "string"
}

Conclusiones.

El Xposer tiene como funciones las de enrutar los consumos de API externos, hacia Banckend Integrators Servers o Rutas REST, así como a Mockups configurados dentro del mismo Xposer.

A través de su motor de reglas, fácilmente se puede configurar el comportamiento de una ruta, basada en el consumidor que llega a ella. También es posible, enrutar hacia diferentes destinos, agregando posibles estrategias de consumo segmentado, lo que puede ayudar a controlar el tráfico hacia los diferentes endpoints.

Este componente sirve como punto central de consumo, y debido a su independencia de operación, no requiere una base de datos para operar. Toda su configuración es leída desde archivos JSON que contienen la definición de los comportamientos, rutas y elementos autorizados para consumir los servicios del mismo.

Su disponibilidad en contenedores, lo hacen excelente para entornos de HCI ( Hyper Convergencia de Infraestructura). También es posible utilizar un Virtual Appliance para arquitecturas Intel y AMD x64 y ARM 64, lo que permite su existencia en ambientes de optimización de consumo eléctrico.