Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo controlar la identidad del usuario dentro de los microservicios



Todos están entusiasmados con los microservicios , pero la implementación real es escasa. Quizás la razón sea que las personas no tienen claro cómo estos servicios se comunican entre sí; especialmente complicado es mantener adecuadamente la gestión de identidad y acceso a través de un mar de servicios independientes.

A diferencia de una estructura monolítica tradicional que puede tener un solo portal de seguridad, los microservicios plantean muchos problemas. ¿Cada servicio debería tener su propio firewall de seguridad independiente? ¿Cómo se debe distribuir la identidad entre microservicios y en todo mi sistema? ¿Cuál es el método más eficaz para el intercambio de datos de usuarios?

Existen técnicas inteligentes que aprovechan las tecnologías comunes para no solo autorizar, sino también realizar la delegación en todo el sistema. En este artículo, identificaremos cómo implementar flujos de OAuth y OpenID Connect utilizando JSON Web Tokens para lograr el objetivo final de crear un mecanismo de autenticación distribuido para microservicios : un proceso de administración de identidad donde todo es autónomo, estandarizado, seguro y lo mejor de todo: fácil de replicar.

¿Qué son los microservicios, nuevamente?

microservices_nordic_apis_microservices

Arquitectura de microservicio

Para aquellos lectores que no están bien versados ​​en las últimas tendencias de discusión web, el enfoque de diseño de microservicios es una forma de diseñar conjuntos de servicios web en componentes especializados independientes. Estos componentes están hechos para satisfacer una función muy específica y son completamente independientes, implementados como entornos separados. La capacidad de recompilar unidades individuales significa que el desarrollo y el escalado pueden ser mucho más fáciles dentro de un sistema que usa microservicios .

 

monolithic_architecture_nordic_apis

Diseño monolítico

Esta arquitectura se opone al enfoque monolítico tradicional que consolida todos los componentes web en un solo sistema. La desventaja de un diseño monolítico es que los ciclos de control de versiones son arduos y la escalabilidad es lenta. Todo el sistema debe implementarse continuamente, ya que está empaquetado.

El movimiento hacia los microservicios podría tener repercusiones dramáticas en toda la industria, lo que permitiría a las organizaciones de SaaS implementar muchos servicios pequeños que ya no dependen de grandes revisiones de sistemas, facilitando el desarrollo y en el lado de cara al usuario, permitiendo portales de selección y elección fáciles para que los usuarios los personalicen. servicios a sus necesidades individuales.

Lo bueno, lo malo y lo que debería hacer mejor: lea nuestra publicación sobre las mejores prácticas de microservicios

Genial, ¿cuál es el problema?

monolithic_request_flow

Flujo monolítico simplificado

El problema al que nos enfrentamos es que los microservicios no se prestan al modo tradicional de control de identidad . En un sistema monolítico, la seguridad funciona simplemente de la siguiente manera:

  1. Averigua quién es la persona que llama
  2. Transmitir credenciales a otros componentes cuando se llama
  3. Almacene la información del usuario en un repositorio de datos

Dado que los componentes están unidos dentro de esta estructura, pueden compartir un solo firewall de seguridad. Comparten el estado del usuario a medida que lo reciben y también pueden compartir el acceso al mismo repositorio de datos del usuario.

microservices_incorrect_flow_microservices

El problema con la seguridad de los microservicios

Si la misma técnica se aplicara a microservicios individuales, sería extremadamente ineficiente. No es necesario tener una barrera de seguridad independiente, o un administrador de solicitudes, para que cada servicio autentique la identidad. Esto implicaría llamar a un servicio de autenticación para completar el objeto para manejar la solicitud y responder en cada instancia.

 

 

La solución: OAuth como protocolo de delegación

Existe un método que permite combinar los beneficios de la implementación aislada con la facilidad de una identidad federada. Jacob Ideskog de Curity cree que para lograr este OAuth debe interpretarse no como Autenticación, ni como Autorización, sino como Delegación .

En el mundo real, la delegación es donde delegas a alguien para que haga algo por ti. En el ámbito web, el mensaje subyacente está ahí, pero también significa tener la capacidad de ofrecer, aceptar o negar el intercambio de datos. Considerar OAuth como un protocolo de delegación puede ayudar en la creación de microservicios o API escalables.

Para comprender este proceso, primero diseñaremos un flujo OAuth estándar para un caso de uso simple. Supongamos que necesitamos acceder a la cuenta de correo electrónico de un usuario para una aplicación simple que organiza el correo electrónico de un usuario, tal vez para enviar mensajes SMS como notificaciones. OAuth tiene los siguientes cuatro actores principales:

  • Propietario del recurso (RO) : el usuario
  • Cliente : la aplicación web o móvil
  • Servicio de autorización (AS) : servidor OAuth 2.0
  • Resource Server (RS) : donde se almacena el servicio real

Un ejemplo simplificado de un flujo de OAuth 2

En nuestra situación, la aplicación (el Cliente), necesita acceder a la cuenta de correo electrónico (el servidor de recursos) para recopilar correos electrónicos antes de que pueda organizarlos para crear el sistema de notificación. En un flujo de OAuth simplificado, un proceso de aprobación sería el siguiente:

  1. El cliente solicita acceso al servidor de recursos llamando al servidor de autorización.
  2. El servidor de autorización redirige para permitir que el usuario se autentique, lo que generalmente se realiza dentro de un navegador. Básicamente, se trata de iniciar sesión en un servidor de autorización, no en la aplicación.
  3. El servidor de autorización valida las credenciales del usuario y proporciona un testigo de acceso al cliente, que se puede utilizar para llamar al servidor de recursos
  4. El cliente envía el token a la de recursos del servidor
  5. El servidor de recursos pregunta al servidor de autorización si el token es válido.
  6. El servidor de autorización valida el token , devolviendo información relevante al servidor de recursos, es decir, el tiempo hasta el vencimiento del token, a quién pertenece el token.
  7. El servidor de recursos a continuación proporciona datos al cliente . En nuestro caso, los correos electrónicos solicitados se desbloquean y se entregan al cliente.

Un factor importante a tener en cuenta dentro de este flujo es que el Cliente, nuestra aplicación de notificación por correo electrónico, no sabe nada sobre el usuario en esta etapa. El token que se envió al cliente era completamente opaco, solo una cadena de caracteres aleatorios. Aunque se trata de un intercambio seguro, los datos del token son en sí mismos inútiles para el cliente. Por tanto, el intercambio proporciona acceso para el cliente, pero no información del usuario. ¿Qué pasaría si nuestra aplicación necesitara personalizar la experiencia del usuario (UX) en función del nivel de membresía al que pertenecía el usuario, un grupo del que era miembro, dónde se encontraba, su idioma preferido, etc.? Muchas aplicaciones brindan este tipo de experiencia y para eso requieren información adicional del usuario.

Descubra cómo las API están alterando nuestra forma de pensar

El flujo de OpenID Connect

Supongamos que estamos mejorando el cliente del servicio de correo electrónico para que no solo organice sus correos electrónicos, sino que también los almacene y los traduzca a otro idioma. En este caso, el cliente querrá recuperar datos de usuario adicionales y almacenarlos en sus propias sesiones de usuario.

Para darle al cliente algo diferente al token opaco provisto en el flujo de OAuth, use un flujo alternativo definido en OpenID Connect . En este proceso, el servidor de autorización, que también se denomina proveedor de OpenID Connect (OP), devuelve un token de identificación junto con el token de acceso al cliente. El flujo es el siguiente:

  1. El cliente solicita acceso al servidor de recursos llamando al servidor de autorización habilitado para Open ID Connect  .
  2. El servidor de autorización redirige para permitir que el usuario se autentique.
  3. El servidor de autorización valida las credenciales del usuario y proporciona un testigo de acceso y un token de ID para el cliente.
  4. El cliente utiliza este token de identificación para mejorar la experiencia de usuario y normalmente almacena los datos del usuario en su propia sesión.
  5. El cliente envía el testigo de acceso al servidor de recursos
  6. El servidor de recursos responde, entregando los datos (los correos electrónicos) al cliente .

SSO_with_OpenIdConnect_microservices

El token de ID contiene información sobre el usuario, como cómo se autenticó, el nombre, el correo electrónico y cualquier número de puntos de datos personalizados de un usuario. Este token de ID toma la forma de un JSON Web Token (JWT), que es una compilación codificada y firmada de documentos JSON. El documento incluye un encabezado, un cuerpo y una firma adjunta al mensaje. Datos + Firma = JWT.

Con un JWT, puede acceder a la parte pública de un certificado, validar la firma y comprender que se emitió esta sesión de autenticación, verificando que el usuario ha sido autenticado. Una faceta importante de este enfoque es que los tokens de ID establecen confianza entre el servidor de autorización / proveedor de Open ID Connect y el cliente.

Leer más: Definición de autenticación, autorización, federación y delegación

Uso de JWT para tokens de acceso de OAuth

Incluso si no usamos OpenID Connect, los JWT se pueden usar para muchas cosas. Un sistema puede estandarizarse mediante el uso de JWT para pasar datos de usuario entre servicios individuales. Revisemos los tipos de tokens de acceso de OAuth para ver cómo implementar de manera inteligente el control de identidad seguro dentro de la arquitectura de microservicios.

Por referencia: Token de acceso estándar

user_value

Este tipo de token no contiene información fuera de la red, simplemente apunta a un espacio donde se encuentra la información. Esta cadena opaca no significa nada para el usuario y, como es aleatoria, no se puede descifrar fácilmente. Esta es la forma estándar de un token de acceso, sin contenido extraño, simplemente se usa para que un cliente obtenga acceso a los datos.

 

Por valor: JSON Web Token

referencia_usuario

Este tipo puede contener información de usuario necesaria que el cliente requiere. Los datos se compilan y se insertan en el mensaje como un token de acceso. Este es un método eficaz porque elimina la necesidad de volver a llamar para obtener información adicional. Si se expone a través de la web, una desventaja es que esta información pública del usuario se puede leer fácilmente, lo que expone los datos a un riesgo innecesario de intentos de descifrado para descifrar códigos.

La solución alternativa: externa frente a interna

Para limitar este riesgo de exposición, Iskedog recomienda dividir la forma en que se utilizan los tokens. Lo que se suele hacer es el siguiente:

  1. El token de referencia lo emite el servidor de autorización. El cliente envía de vuelta cuando es el momento de llamar a la API.
  2. En el medio: el servidor de autorización  valida el token y responde con un JWT .
  3. El JWT se hace pasar más a lo largo de la red.

En el medio, básicamente creamos un firewall, un servidor de autorización que actúa como un punto de traducción de tokens para la API. El servidor de autorización traducirá el token, ya sea para un proxy inverso simple o un firewall API a gran escala. Sin embargo, el servidor de autorización no debería estar en la "ruta de tráfico"; el proxy inverso encuentra el token y llama al servidor de autorización para traducirlo.

Deje que todos los microservicios consuman JWT

Entonces, para actualizar, con la seguridad de microservicios tenemos dos problemas:

  • Necesitamos identificar al usuario varias veces : hemos mostrado cómo dejar la autenticación a OAuth y al servidor OpenID Connect, para que los microservicios proporcionen acceso con éxito si alguien tiene derecho a usar los datos.
  • Tenemos que crear y almacenar sesiones de usuario : los JWT contienen la información necesaria para ayudar a almacenar sesiones de usuario. Si cada servicio puede comprender un token web JSON, entonces ha distribuido su mecanismo de identidad, lo que le permite transportar la identidad a través de su sistema.

En la arquitectura de microservicio, un token de acceso no debe tratarse como un objeto de solicitud, sino como un objeto de identidad . Como el proceso descrito anteriormente requiere traducción, los JWT deben ser traducidos por un proxy sin estado frontal, utilizado para tomar un token de referencia y convertirlo en un token de valor para luego distribuirlo por toda la red.

token_translation_microservices

¿Por qué hacer esto?

Al usar OAuth con OpenID Connect y al crear una arquitectura basada en estándares que acepta universalmente los JWT, el resultado final es un mecanismo de identidad distribuido que es autónomo y fácil de replicar. Construir una biblioteca que entienda JWT es una tarea muy simple. En este entorno, el acceso y los datos del usuario están protegidos. La creación de microservicios que se comuniquen bien y accedan de forma segura a la información del usuario puede aumentar en gran medida la agilidad de todo el sistema, así como la calidad de la experiencia del usuario final.

Consulte esta charla para obtener más información:

Vea la charla de Jacob Ideskog de Curity en un evento de API nórdicas. Diapositivas aquí .

Publicar un comentario

0 Comentarios