REST Assured tiene una especificación de proxy que lleva juntas la dirección y las credenciales del intermediario:

import static io.restassured.RestAssured.given;
import io.restassured.specification.ProxySpecification;

var proxy = ProxySpecification.host("proxy.example")
    .withPort(8080)
    .withScheme("http")
    .withAuth(proxyUser, proxyPassword);

var request = given().proxy(proxy);

La aplicación proporciona proxyUser y proxyPassword desde su fuente habitual de credenciales. El fragmento construye una especificación de solicitud; invoque la URL de la API deseada mediante request con el código habitual de solicitud y aserción de la prueba.

El esquema http describe el punto de conexión del proxy. La URL de la API puede seguir siendo HTTPS. El mecanismo withAuth de REST Assured proporciona autenticación básica de proxy; no negocia todos los esquemas de autenticación corporativos solo porque se hayan facilitado dos cadenas.

Coloque las credenciales de la API en la configuración de autenticación propia de la API. Evite sustituir la cuenta del proxy por una cabecera Authorization genérica o por una contraseña de servicio. En HTTPS, la autenticación con el intermediario puede ser necesaria al establecer CONNECT, antes de que exista el intercambio HTTP con el destino.

Cuando el fallo restante es la confianza en el certificado

Un desafío CONNECT rechazado y un error de validación del certificado TLS son resultados distintos. Si el CA requerido y gestionado por la organización falta en la configuración de confianza del cliente, obtenga ese CA por el canal administrativo aprobado y configure el truststore del cliente de pruebas.

REST Assured expone trustStore para ese propósito. Un truststore cambia qué emisores confía el cliente HTTPS; no elige el proxy ni proporciona su inicio de sesión. Mantenga activa la validación del nombre de host y del certificado en lugar de usar un handshake accept-all para aceptar cualquier certificado que se presente.

Artículos relacionados