HTTP Spec: cabeceras Autorización proxy y autorización

Question

así que estoy tratando de implementar el siguiente escenario:

• Una aplicación está protegido por la autenticación básica. Digamos que está alojado en app.com
• Un proxy HTTP, en frente de la aplicación, también requiere autenticación. Está alojado en proxy.com

Por ello, el usuario debe proporcionar credenciales, tanto para el proxy y la aplicación de la misma solicitud, por lo tanto tiene diferentes pares de nombre de usuario/contraseña: un par para autenticar a sí mismo en contra de la aplicación, y otro nombre de usuario/contraseña para autenticarse contra el proxy.

Después de leer las especificaciones, no estoy seguro de cómo debo implementar esto. Lo que estaba pensando hacer es:

1. El usuario realiza una solicitud HTTP al proxy sin ningún tipo de autenticación.
2. El proxy responde 407 Proxy Authentication Required y devuelve un encabezado Proxy-Authenticate en el formato de: "Proxy-Authenticate: Basic realm="proxy.com".
   Pregunta: ¿Este encabezado Proxy-Authenticate está configurado correctamente?
3. El cliente vuelve a intentar la solicitud con un encabezado Proxy-Authorization, que es la representación Base64 del proxy username:password.
4. Esta vez el proxy autentica la solicitud, pero luego la aplicación responde con un encabezado 401 Unauthorized. El usuario fue autenticado por el proxy, pero no por la aplicación. La aplicación agrega un encabezado WWW-Authenticate a la respuesta como WWW-Authenticate: Basic realm="app.com". Pregunta: este valor de encabezado es correcto ¿no?
5. El cliente vuelve a intentar la solicitud con un encabezado Proxy-Authorization y un encabezado Authorization valorado con la representación Base64 de la aplicación username:password.
6. En este punto, el proxy autentica correctamente la solicitud, reenvía la solicitud a la aplicación que autentica también al usuario. Y el cliente finalmente obtiene una respuesta.

¿Es correcto todo el flujo de trabajo?

Answer 1

Sí, parece un flujo de trabajo válido para la situación que describió, y los encabezados de autenticación parecen estar en el formato correcto.

Es interesante observar que es posible, aunque poco probable, que una conexión determinada implique múltiples proxies que están encadenados entre sí, y cada uno puede requerir autenticación. En este caso, el lado del cliente de cada proxy intermediario recibiría un mensaje 407 Proxy Authentication Required y él mismo lo repetiría con el encabezado Proxy-Authorization; los encabezados Proxy-Authenticate y Proxy-Authorization son encabezados de un solo salto que no se pasan de un servidor a otro, pero WWW-Authenticate y Authorization son encabezados de extremo a extremo que se consideran desde el cliente hasta el servidor final, transmitidos textualmente por los intermediarios.

Dado que el esquema Basic envía la contraseña sin cifrar (base64 es una codificación reversible), se usa con mayor frecuencia a través de SSL.Este escenario se lleva a cabo de una manera diferente, ya que es deseable evitar que el proxy de ver la contraseña enviada al servidor definitiva:

• el cliente abre un canal SSL al proxy para iniciar la solicitud, pero en lugar de al enviar una solicitud HTTP regular, enviaría a special CONNECT request (aún con un encabezado Proxy-Authorization) para abrir un túnel TCP al servidor remoto.
• El cliente luego procede a crear otro canal SSL anidado dentro del primero, sobre el cual transfiere el mensaje HTTP final incluyendo el encabezado Authorization.

En este escenario, el proxy solo conoce el host y el puerto al que se conectó el cliente, no lo que se transmitió o recibió a través del canal SSL interno. Además, el uso de canales anidados permite al cliente "ver" los certificados SSL tanto del proxy como del servidor, permitiendo que la identidad de ambos se autentique.