Estrategia de autenticación de microservicios


138

Me está costando elegir una estrategia de autenticación decente / segura para una arquitectura de microservicio. La única publicación SO que encontré sobre el tema es esta: Inicio de sesión único en arquitectura de microservicios

Mi idea aquí es tener en cada servicio (por ejemplo, autenticación, mensajería, notificación, perfil, etc.) una referencia única para cada usuario (bastante lógicamente, entonces el suyo user_id) y la posibilidad de obtener el usuario actual idsi está conectado.

De mis investigaciones, veo que hay dos estrategias posibles:

1. Arquitectura compartida

Arquitectura compartida

En esta estrategia, la aplicación de autenticación es un servicio entre otros. Pero cada servicio debe poder realizar la conversión session_id=> user_idpor lo que debe ser muy simple. Por eso pensé en Redis, que almacenaría la clave: el valor session_id:user_id.

2. Arquitectura de firewall

Arquitectura de cortafuegos

En esta estrategia, el almacenamiento de la sesión realmente no importa, ya que solo lo maneja la aplicación de autenticación. Luego user_idse puede reenviar a otros servicios. Pensé en Rails + Devise (+ Redis o mem-cached, o almacenamiento de cookies, etc.) pero hay muchas posibilidades. Lo único que importa es que el Servicio X nunca necesitará autenticar al usuario.


¿Cómo se comparan esas dos soluciones en términos de:

  • seguridad
  • robustez
  • escalabilidad
  • facilidad de uso

¿O tal vez sugerirías otra solución que no he mencionado aquí?

Me gusta más la solución n. ° 1, pero no he encontrado mucha implementación predeterminada que me asegure en el hecho de que voy en la dirección correcta.

Espero que mi pregunta no se cierre. Realmente no sé dónde más preguntarlo.

Gracias por adelantado


1
¿Podría proporcionar más detalles sobre lo que está tratando de lograr? En el primer caso, ¿se realiza la autenticación contra Redis o en los propios servicios? Falta Redis en el segundo diagrama, ¿es intencional?
Plamen Petrov

He agregado alguna información. Por favor, hágamelo saber que aún no está claro. ¡Gracias!
Augustin Riedinger

¿Has pensado en la idea de crear un microservicio que use el Protocolo OAuth y el token de tu otro servicio?
Tiarê Balbi

Tengo curiosidad acerca de esta solución, pero todavía no entiendo cómo funcionará en la práctica. ¿Sabes dónde puedo encontrar algunas implementaciones estándar?
Augustin Riedinger

@AugustinRiedinger, gracias por publicar esto. También estoy rompiendo mi aplicación web monolítica en micro servicios al dar pequeños pasos. En su caso, ¿son los Servicios 1-n sin estado o con estado completo? En caso de que estén completos, ¿ha pensado en administrar sesiones en cada uno de estos servicios? Gracias
Manchanda. P

Respuestas:


61

Según lo que entiendo, una buena manera de resolverlo es utilizando el protocolo OAuth 2 (puede encontrar un poco más de información al respecto en http://oauth.net/2/ )

Cuando su usuario inicie sesión en su aplicación, recibirá un token y con este token podrá enviarlo a otros servicios para identificarlos en la solicitud.

Modelo OAuth 2

Ejemplo de diseño de microservicio encadenado Modelo de arquitectura

Recursos:


1
Gracias está bastante claro. Encontré este muy buen artículo que descompone prácticamente la misma solución: dejanglozic.com/2014/10/07/…
Augustin Riedinger

16
Su respuesta es excelente, pero ¿cómo puede manejar un token aleatorio el token generado desde la puerta de enlace API (desde su interior o en un AuthMicroService), cuyo objetivo no es autenticar, y probablemente no tenga una buena gestión dentro de su código de negocios?
mfrachet

Por ejemplo, puede usar Netflix Zuul para enviar el token recibido en la puerta de enlace a todos los servicios y ellos conocerán la información del usuario. docs.spring.io/spring-boot/docs/current/reference/htmlsingle/…
Tiarê Balbi

Otra cosa interesante sobre el uso de OAuth2 entre servicios es que puede tener puntos finales que distinguen entre acciones autenticadas por el servicio y autenticadas por el usuario.
cmp

2
OAuth es más acerca de otorgar a un sistema acceso a los datos de un usuario contenidos en otro sistema. Esto para mí parece un buen caso para SAML.
Rob Grant

8

Respuesta corta: use la autenticación basada en token tipo Oauth2.0, que se puede usar en cualquier tipo de aplicaciones, como una aplicación web o una aplicación móvil. La secuencia de pasos involucrados para una aplicación web sería entonces

  1. autenticar contra proveedor de identificación
  2. mantener el token de acceso en cookie
  3. acceder a las páginas en la aplicación web
  4. llama a los servicios

El siguiente diagrama muestra los componentes que serían necesarios. Dicha arquitectura que separa la API de la web y de datos proporcionará una buena escalabilidad, resistencia y estabilidad.

ingrese la descripción de la imagen aquí


¿AWS Lambda no se vuelve "frío" y toma tiempo arrancar? Eso haría que el inicio de sesión sea lento, ¿no?
tsuz

@tsuz, AWS ahora ha introducido la función de concurrencia en lambda donde puede reservar la concurrencia. Con esto podría solucionar el problema de arranque en frío. docs.aws.amazon.com/lambda/latest/dg/…
Sandeep Nair

Me hubiera encantado haber visto esta respuesta años antes, es increíblemente simple entender cómo la arquitectura de microservicios con autenticación y autorización de microservicios independientes se puede organizar para dar acceso a otros servicios
brayancastrop

@Sandeep, creo que te refieres a la concurrencia aprovisionada y no reservada.
Anil Kumar

0

El patrón de puerta de enlace API debe usarse para implementar esto usando OpenID Connect. El IDP autenticará al usuario y obtendrá el token JWT del servidor de autorización. Ahora el sistema de puerta de enlace API puede almacenar este token en la base de datos Redis y configurar la cookie en el navegador. API Gateway usará la cookie para validar la solicitud del usuario y enviará el token a los Microservicios.

API Gateway actúa como un único punto de entrada para todo tipo de aplicaciones de clientes, como la aplicación de cliente de script java público, la aplicación web tradicional, la aplicación móvil nativa y las aplicaciones de cliente de terceros en la arquitectura Microservice.

Puede encontrar más detalles al respecto en http://proficientblog.com/microservices-security/


-2

puede usar el servidor de identidad 4 para fines de autenticación y autorización

debe usar Firewall Architecture, por lo tanto, tiene más control sobre seguridad, robustez, escalabilidad y facilidad de uso

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.