security - orientada - microservicios spring boot
Inicio de sesión único en la arquitectura de Microservice (2)
Al implementar una arquitectura de microservicio en mi trabajo anterior, decidimos que el mejor enfoque estaba alineado con el n. ° 1, agregar servicio de identidad y autorizar el acceso al servicio a través de él. En nuestro caso, esto se hizo con tokens. Si recibimos una solicitud con un token de autorización, podemos verificar ese token con el servicio de identidad si fue la primera llamada en la sesión del usuario con el servicio. Una vez que se validó el token, se guardó en la sesión para que las llamadas subsiguientes en la sesión del usuario no tuvieran que realizar la llamada adicional. También puede crear un trabajo programado si los tokens necesitan actualizarse en esa sesión.
En esta situación, nos autenticamos con un punto final OAuth 2.0 y el token se agregó al encabezado HTTP para las llamadas a nuestro dominio. Todos los servicios se enrutaron 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 los servicios de la aplicación a los que el usuario daría permiso para su cuenta.
Una adición a este enfoque fue que el servicio de identidad proporcionaría la biblioteca cliente proxy que se agregaría a la cadena de filtro de solicitud HTTP y manejaría el proceso de autorización para el servicio. El servicio se configuraría para consumir la biblioteca cliente proxy del servicio de identidad. Como utilizábamos Dropwizard, este proxy se convertiría en un Módulo Dropwizard que iniciaba el filtro en el proceso de servicio en ejecución. Esto permitió actualizaciones para el servicio de identidad que también tenía una actualización complementaria del lado del cliente para ser fácilmente consumida por los servicios dependientes, siempre y cuando la interfaz no cambiara significativamente.
Nuestra arquitectura de implementación se extendió a través de 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 compañía, 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íseme si tiene alguna otra pregunta.
Estoy intentando diseñar un proyecto de campo verde que tendrá varios servicios (datos de servicio) y aplicaciones web (que sirven HTML). He leído sobre microservicios y se ven bien.
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.
Puedo pensar en varios enfoques:
Agregar servicio de identidad y aplicación. Cualquier servicio que tenga recursos protegidos se comunicará con el servicio Identity para asegurarse de que las credenciales que posee sean válidas. Si no lo son, redirigirá al usuario para la autenticación.
Use 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.
Chris Sterling explicó anteriormente la práctica de autenticación estándar y tiene mucho sentido. Solo quiero poner otro pensamiento aquí por algunas razones prácticas.
Implementamos servicios de autenticación y varios otros micro servicios confiando en el 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. Cambiamos un poco la arquitectura para evitar demasiados viajes redondos.
El servidor de autenticación será contactado una sola vez con credenciales y generará el token basado en una clave privada. La clave pública correspondiente se instalará en cada cliente (servidor de microservicios) que podrá validar la clave de autenticación sin ponerse en contacto con el servidor de autenticación. La clave contiene tiempo generado y una utilidad cliente instalada en micro servicio también tendrá validez. Aunque no se trata de una implementación estándar, tenemos bastante éxito con este modelo, especialmente cuando todos los micro servicios están alojados internamente.