Menu

Microservicios de seguridad con Oauth2

Uno de los aspectos más importantes a considerar cuando se expone una API de acceso público que consta de muchos microservicios es la seguridad. Spring tiene algunas características y marcos interesantes que facilitan la configuración de la seguridad de nuestros microservicios. En este artículo, le mostraré cómo usar Spring Cloud y Oauth2 para proporcionar seguridad de acceso de token detrás de la puerta de enlace API.

El estándar OAuth2

Es utilizado actualmente por todos los sitios web principales que le permiten acceder a sus recursos a través de la API compartida. Es un estándar de autorización abierto que permite a los usuarios compartir sus recursos privados almacenados de una página a otra sin tener que ingresar al servicio de sus credenciales. Estos son términos básicos relacionados con oauth2.

  • Propietario del recurso : disponer del acceso al recurso
  • Servidor de recursos : servidor que almacena los recursos del propietario que se pueden compartir con un token especial
  • Servidor de autorización : administra la asignación de claves, tokens y otros códigos de acceso a recursos temporales. También debe garantizar que el acceso se otorga a la persona relevante.
  • Token de acceso : la clave que permite acceder a un recurso
  • Autorización de concesión – otorga permiso para el acceso. Hay diferentes formas de confirmar el acceso: código de autorización, implícito, credenciales de contraseña de propietario de recurso y credenciales de cliente

 

El flujo de este protocolo tiene tres pasos principales. Al principio, la solicitud de autorización se envía al Propietario del recurso. Después de la respuesta del Propietario del recurso, enviamos la solicitud de autorización de autorización al Servidor de autorización y recibimos el token de acceso. Finalmente, enviamos este token de acceso a Resource Server y, si es válido, la API sirve el recurso a la aplicación.

La imagen de abajo muestra la arquitectura de nuestra muestra. Tenemos API Gateway (Zuul) que sirve como proxy de nuestras solicitudes al servidor de autorización y dos instancias de microservicio de cuenta. El servidor de autorización es algún tipo de servicio de infraestructura que proporciona mecanismos de seguridad outh2. También tenemos un servicio de descubrimiento (Eureka) donde todos nuestros microservicios están registrados.

Para nuestra muestra no proporcionaremos ninguna seguridad en la puerta de enlace API. Solo tiene que enviar las solicitudes de los clientes al servidor de autorización y microservicios de cuenta. En la configuración de la puerta de enlace de Zuul visible a continuación, establecemos lapropiedad sensitiveHeaders en un valor vacío para habilitar el encabezado HTTP de Autorización en adelante. De forma predeterminada, Zuul cortó ese encabezado al tiempo que reenvía nuestra solicitud a la API de destino, lo cual es incorrecto debido a la autorización básica exigida por nuestros servicios detrás del gateway.

La clase principal dentro del código fuente de la puerta de enlace es muy simple. Solo tiene que habilitar la función proxy de Zuul y el cliente de descubrimiento para recopilar servicios del registro de Eureka.

Servidor de Autorización

Nuestro servidor de autorizaciones es lo más sencillo posible. Se basa en la configuración de seguridad predeterminada de Spring. Los detalles de autorización del cliente se almacenan en un repositorio en memoria. Por supuesto, en el modo de producción, le gustaría usar otras implementaciones en lugar de un repositorio en memoria como el origen de datos JDBC y el almacén de tokens. Puede leer más sobre los mecanismos de autorización de Spring en  Spring Security Reference  y  Spring Boot Security . Aquí hay un fragmento de configuración de application.yml . Proporcionamos al usuario datos de autenticación básicos y credenciales de seguridad básicas para el  punto final / token :  client-idclient-secret. Las credenciales de usuario son los datos normales de usuario de Spring Security.

Aquí está la clase principal de nuestro servidor de autenticación con  @EnableAuthorizationServer. También expusimos un punto final REST con detalles de autenticación de usuario para el servicio de cuenta y habilitamos el registro y descubrimiento de Eureka para clientes.

Aplicación – microservicio de cuenta

Nuestro microservicio de muestra solo tiene un punto final para la solicitud @GET que siempre devuelve la misma cuenta. En la clase principal, el servidor de recursos y el descubrimiento de Eureka están habilitados. La configuración del servicio es trivial.

Pruebas

Solo necesitamos un navegador web y un cliente REST (por ejemplo, el cliente Chrome Advanced REST) ​​para probar nuestra solución. Vamos a empezar enviando la solicitud de autorización al propietario del recurso. Podemos llamar a un punto final autorizado a través de Zuul en el navegador web.

http: // localhost: 8765 / uaa / oauth / authorize? response_type = token & client_id = acme & redirect_uri = http: //example.com&scope=openid&state=48532

Después de enviar esta solicitud deberíamos ver la página de abajo. Seleccione Aprobar y haga clic en Autorizar para solicitar un token de acceso del servidor de autorización. Si la identidad de la aplicación está autenticada y la concesión de la autorización es válida, se debe devolver un token de acceso a la aplicación en la respuesta HTTP.

http://example.com/#access_token= b1acaa35-1ebd-4995-987d-56ee1c0619e5 & token_type = bearer & state = 48532 & expires_in = 43199

Y el paso final es llamar al punto final de la cuenta utilizando el token de acceso. Tuvimos que ponerlo en el encabezado Autorización como token de portador. En la aplicación de ejemplo, el nivel de registro para la operación de seguridad está establecido en TRACE para que pueda descubrir fácilmente qué sucedió si algo sale mal.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *