Inicio de sesión único en la Arquitectura de Microservicios
Estoy tratando de diseñar un proyecto de campo verde que tendrá varios servicios (sirviendo datos) y aplicaciones web (sirviendo HTML). He leído acerca de los microservicios y se ven como una buena opción.
El problema que todavía tengo es cómo implementar SSO. Quiero que el usuario se autentique una vez y tenga acceso a todos los diferentes servicios y aplicaciones.
Se me ocurren varios enfoques:
Agregue el servicio de identidad y la aplicación. Cualquier servicio que haya protegido los recursos hablarán con el servicio de identidad para asegurarse de que las credenciales que tiene son válidas. Si no lo son, redirigirá al usuario para la autenticación.
Utilice un estándar web como OpenID y haga que cada servicio maneje sus propias identidades. Esto significa que el usuario tendrá que autorizar individualmente cada servicio / aplicación, pero después de eso será SSO.
Estaré feliz de escuchar otras ideas. Si un PaaS específico (como Heroku) tiene una solución propietaria que también sería aceptable.
2 answers
Mientras implementaba una arquitectura de microservicios en mi trabajo anterior, decidimos que el mejor enfoque estaba alineado con el #1, Agregar servicio de identidad y autorizar el acceso al servicio a través de él. En nuestro caso esto se hizo con fichas. Si una solicitud venía con un token de autorización, entonces podríamos verificar ese token con el servicio de identidad si era la primera llamada en la sesión del usuario con el servicio. Una vez que el token había sido validado, se guardaba en la sesión, por lo que las llamadas posteriores en el sesión no tuvo que hacer la llamada adicional. También puede crear un trabajo programado si los tokens deben actualizarse en esa sesión.
En esta situación nos estábamos autenticando con un punto final OAuth 2.0 y el token se agregó al encabezado HTTP para las llamadas a nuestro dominio. Todos los servicios fueron enrutados desde ese dominio para que pudiéramos obtener el token del encabezado HTTP. Dado que todos éramos parte del mismo ecosistema de aplicaciones, la autorización inicial de OAuth 2.0 enumeraría la aplicación servicios a los que el usuario estaría dando permiso para su cuenta.
Una adición a este enfoque fue que el servicio de identidad proporcionaría la biblioteca de cliente proxy que se agregaría a la cadena de filtros de solicitud HTTP y manejaría el proceso de autorización al servicio. El servicio se configuraría para consumir la biblioteca cliente proxy del servicio de identidad. Desde que estábamos usando Dropwizard este proxy se convertiría en un Módulo Dropwizard bootstrapping el filtro en el ejecución del proceso de servicio. Esto permitió que las actualizaciones del servicio de identidad que también tenían una actualización complementaria del lado del cliente fueran consumidas fácilmente por los servicios dependientes, siempre y cuando la interfaz no cambiara significativamente.
Nuestra arquitectura de implementación se extendió por AWS Virtual Private Cloud (VPC) y los centros de datos de nuestra propia empresa. El servicio de autenticación OAuth 2.0 se ubicó en el centro de datos de la empresa, mientras que todos nuestros servicios de aplicaciones se implementaron en AWS VPC.
Espero que el enfoque que tomamos sea útil para su decisión. Avísame si tienes alguna otra pregunta.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-12-04 00:29:53
Chris Sterling explicó la práctica de autenticación estándar anteriormente y tiene sentido absoluto. Sólo quiero poner otro pensamiento aquí por algunas razones prácticas.
Implementamos servicios de autenticación y varios otros micro servicios que dependen del servidor de autenticación para autorizar recursos. En algún momento nos encontramos con problemas de rendimiento debido a demasiados viajes de ida y vuelta al servidor de autenticación, también tuvimos problemas de escalabilidad para el servidor de autenticación a medida que aumentaba el número de micro servicios. Nos cambió un poco la arquitectura para evitar demasiados viajes de ida y vuelta.
El servidor de autenticación solo será contactado una vez con credenciales y generará el token basado en una clave privada. La clave pública correspondiente se instalará en cada cliente (servidor de micro servicio) que podrá validar la clave de autenticación sin ponerse en contacto con el servidor de autenticación. La clave contiene el tiempo generado y una utilidad de cliente instalada en el servicio micro también tendrá validez. A pesar de que no era estándar implementación tenemos bastante éxito con este modelo, especialmente cuando todos los micro servicios están alojados internamente.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-12-04 04:53:28