Pasando la identidad del usuario a un servicio REST interno

4

Tengo dos servicios, A y B, que exponen una API HTTP / REST. El servicio A está expuesto al público y autentica a sus usuarios. Delega parte de la carga de trabajo al servicio B, que también debe conocer la identidad del usuario autenticado y realizar algún control de acceso. El servicio B no tiene una dirección IP pública y solo acepta conexiones de servicios en la misma red interna (uno de ellos es el servicio A).

Como considero que la conexión entre A y B es de confianza (ambos están detrás de dos firewalls), simplemente paso la identidad del usuario en un encabezado HTTP personalizado. ¿Hay vulnerabilidades en esta configuración que no estoy pensando? ¿Hay formas estándar de pasar la identidad del usuario en lugar de usar un encabezado HTTP personalizado?

    
pregunta Muton 02.03.2017 - 19:44
fuente

2 respuestas

1

Tengo casi exactamente el mismo problema con dos de mis servicios.

Estoy tomando una ruta ligeramente diferente para resolverlo debido a la siguiente línea de pensamiento: ¿Qué sucede si debido a una mala configuración del firewall o del enrutador, el servicio B de repente se vuelve disponible en Internet o en la red interna? de mi compañia? Hemos tenido cambios en las reglas de firewall sin que nos hayan informado sobre los cambios en el pasado; Así que he crecido con cuidado.

Esto es lo que estoy haciendo actualmente: el Servicio A y B comparten una contraseña secreta que solo ellos saben. Lo uso para crear un hmac sobre una pequeña estructura json (mi "token de acceso") en el servicio A, que básicamente contiene el nombre de usuario del usuario autenticado, un nonce y una fecha de caducidad. Paso el token de acceso y el hmac al servicio B (como una cadena larga codificada en base64 en el encabezado de Autorización estándar). El servicio B luego valida el token de acceso usando el hmac y, si se retira, puede estar razonablemente seguro de que el token de acceso que recibió fue del servicio A. Todo lo que queda es asegurarse de que el token de acceso no haya caducado.

Podrías hacer lo mismo con un JWT, y con la criptografía de clave pública para firmar digitalmente el token de acceso, en lugar de lo que estoy haciendo con un hmac.

Esto no es muy diferente de lo que estás haciendo: compilar mi token de acceso (solo una vez, cuando el usuario inicia sesión en el servicio A) no es mucho trabajo, y ninguno de los dos está verificando el token en el servicio B, pero agrega alguna seguridad adicional, en comparación con su solución.

Al igual que usted, me interesarían las respuestas que describen una forma generalmente aceptada de resolver este problema. Siempre pensé que mi solución era demasiado propia y que podría tener problemas que no puedo resolver de inmediato. ver.

    
respondido por el Pascal 03.03.2017 - 00:40
fuente
0

'Defensa en profundidad' se trata de planificar el fracaso. En este modelo de red, una vulnerabilidad de falsificación de solicitud del lado del servidor (SSRF) sería extremadamente valiosa para un adversario .

Tenga en cuenta que ningún desarrollador pretende implementar software inseguro y, sin embargo, estos problemas son rampantes.

    
respondido por el rook 02.03.2017 - 20:16
fuente

Lea otras preguntas en las etiquetas