Parte 2: Puerta de enlace API y TLS mutuo

En la parte 1 de la serie, analizamos cómo la seguridad federada ayuda a proteger el acceso a los recursos protegidos y elimina la necesidad de presentar credenciales secretas en todas y cada una de las solicitudes de usuario. En esta sección analizaremos el uso de tokens emitidos en la puerta de enlace API tanto para llamar a los servicios de backend como para suscribirse a las notificaciones. Pero antes de sumergirnos en detalles, revisemos qué es la puerta de enlace API y por qué es una parte vital de cualquier arquitectura distribuida, independientemente de si es una nube o local.

En una aplicación tradicional de 3 niveles, los clientes realizan llamadas a las API del servidor que, a su vez, conservan o leen datos de la base de datos y los devuelven al autor de la llamada. A medida que crece el número de servidores, los clientes necesitan saber en qué dirección se encuentran los servicios. Esto se resuelve utilizando varios mecanismos de descubrimiento donde cada servicio en el inicio registra su dirección IP y puerto. Los clientes pueden descubrir servicios dinámicamente y llamar a sus API, sin embargo, las aplicaciones cliente se acoplan a los servicios, ya que conocen todas y cada una de las direcciones físicas del servicio. Otro problema es que cada servicio debe utilizar componentes de autenticación y autorización para ejecutar o rechazar solicitudes de cliente.

Figura 1: Invocación directa de cliente a servidor con detección de servicios

La puerta de enlace API ofrece solución a estos problemas e introduce varias ventajas sobre la comunicación directa de cliente a servicios. Una vez que tenga un único punto a través del cual fluya toda la comunicación con el cliente, puede implementar la autenticación y la autorización en una sola ubicación, haciendo que los servicios backend solo estén orientados al negocio. La puerta de enlace API se conecta a los mismos mecanismos de descubrimiento para descubrir la ubicación de los servicios, pero ahora los servicios pueden residir en otra LAN o incluso en otro centro de datos en otro lado del mundo, y el cliente no conoce ninguna de estas ubicaciones físicas – todo lo que sabe es la dirección de la puerta de enlace API.

Figura 2: Invocación de servicios a través de la puerta de enlace

Otro aspecto importante de la puerta de enlace API es el puente de protocolo y este es un requisito clave cuando se trabaja con sistemas heredados. Las aplicaciones cliente generalmente usan la API REST para ponerse en contacto con la puerta de enlace API, que a su vez puede usar gRPC, Servicios Web, sockets y protocolos propietarios para llamar a los servicios backend y devolver los resultados como JSON sobre HTTP.

Cuando aumenta el rendimiento en la puerta de enlace API, es fácil agregar una capa de almacenamiento en caché y usar patrones de almacenamiento en caché de lectura y escritura subyacente para minimizar el tiempo que se tarda en recuperar recursos de los servicios backend o de varias bases de datos.

Algunos de los lectores entusiastas podrían pensar: «si todo el tráfico pasa por un componente en el sistema, ¿no es un cuello de botella de rendimiento y un único punto de falla?» La respuesta depende de la forma en que implemente y desarrolle las instancias de la puerta de enlace API:

• La puerta de enlace API implementada en múltiples instancias y para lograr esto fácilmente, deben ser sin estado.
• • Puerta de enlace API implementada detrás de L4 NLB (Network Load Balancer) que redistribuye el tráfico de paquetes utilizando un algoritmo round-robin y sondea las instancias de la puerta de enlace API para determinar su estado de salud antes de reenviar cualquier tráfico a ella.

 

Figura 3: Invocación de servicios a través de NLB y puerta de enlace de API

 

Algunas de las otras ventajas de la puerta de enlace API, que no voy a cubrir ampliamente son:

• Agregación de consultas: la capacidad de consultar múltiples servicios de backend en paralelo y devolver datos combinados a los clientes.
• Modelado del tráfico: la capacidad de enrutar las solicitudes de los clientes a diferentes instancias de servicio en función de políticas predefinidas, por ejemplo, al probar nuevas funciones y exponer solo el 20% del tráfico de las solicitudes de los clientes.
• Re-intentos e interruptores automáticos.
• Registro, rastreo distribuido y monitoreo: el trío de observabilidad.
• Limitación de velocidad.
• BFF (Backend for Frontend) – La puerta de enlace API por tipo de aplicación cliente (móvil, web, etc.).

La mayoría de las implementaciones de la puerta de enlace API funcionan como equilibrador de carga L7 inspeccionando parámetros o encabezados de consulta y reenviando solicitudes HTTP a servidores backend. En nuestro caso, necesitábamos una solución personalizada que exponga interfaces REST, GraphQL y Web sockets, pero que se comunique con nuestro bus de servicio y descubrimiento interno utilizando protocolos propietarios.

Basta de información general, volvamos a nuestros tokens emitidos y cómo la puerta de enlace API los usa para autenticar y autorizar las solicitudes de los usuarios.

Después de autenticar correctamente la solicitud de inicio de sesión del usuario, el servidor de autorización codifica las notificaciones en el token emitido y, a continuación, la aplicación cliente utiliza ese token para llamar a la puerta de enlace de API. Las notificaciones de usuario estándar contienen el identificador de usuario del sistema, los roles de usuario y la agencia de usuario. Una vez que llega la solicitud, la puerta de enlace de API valida el token emitido y extrae las notificaciones de él. Los pasos de validación incluyen la comprobación de firmas de token, audiencia, emisor y valores de duración de token. Todo esto hecho de manera sin estado y sin llamar al servidor de autorización (todo lo que se necesita es la parte de clave pública de la clave de seguridad utilizada para firmar el token). Las notificaciones de usuario contienen toda la información necesaria para decidir si el cliente puede acceder a un recurso específico y, una vez que se autorizan esas notificaciones, la puerta de enlace de API detecta la dirección del servidor backend, inicializa un canal de comunicación utilizando la tecnología adecuada para ese servicio y realiza una llamada a la API (o, a veces, varias llamadas a la API a varios servidores) y envía la respuesta de vuelta al autor de la llamada.

Llamar a la API para obtener recursos es solo una parte de la ecuación. ¿Cómo podemos usar los mismos tokens para suscribirnos a las notificaciones publicadas por el servidor? A diferencia de las llamadas a la API que no tienen estado y abren y cierran conexiones en cada llamada, al suscribirse a las notificaciones, el cliente crea un canal seguro para la puerta de enlace de API, generalmente utilizando el protocolo Web Socket, y la puerta de enlace de API envía las notificaciones publicadas por los servicios backend a través de ese canal seguro. La conexión inicial del cliente de Web Socket se autentica y autoriza de la misma manera que se autentica y autoriza la llamada a la API. A continuación, la puerta de enlace de API examina el tiempo de expiración del token y registra un temporizador para desalojar a los clientes suscritos cuyos tokens han caducado. Es responsabilidad de la aplicación cliente renovar el token en la conexión del Web Socket abierto el tiempo suficiente antes de que caduque el token. De esta manera, la conexión permanece abierta mientras la aplicación cliente se esté ejecutando y los tokens se renueven sin problemas en la misma conexión.

Como se mencionó anteriormente, C-Insight es una plataforma de multiagencias, lo que significa que el usuario pertenece a la agencia autorizada a operar solo en entidades que pertenecen a esa agencia, y la puerta de enlace API envía notificaciones observando el reclamo de identificación de la agencia del usuario y reenviando el mensaje solo a los suscriptores permitidos para recibirlo.

En la última parte de la serie, vamos a discutir cómo conectamos los sistemas de sensores locales que se ejecutan en el borde a los servicios que se ejecutan en los centros de datos en la nube de una manera segura y de alto rendimiento.