personalizadas - http headers chrome

Especificación de HTTP: encabezados de autorización y autorizaciones de proxy

Question

Así que estoy tratando de implementar el siguiente escenario:

• Una aplicación está protegida por Basic Autenticación. 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 lo tanto, el usuario debe proporcionar credenciales para el proxy y la aplicación en la misma solicitud, por lo que tiene diferentes pares de nombre de usuario / contraseña: un par para autenticarse contra la aplicación y otro par de 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 a la 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 correctamente configurado?
3. El cliente vuelve a intentar la solicitud con un encabezado Proxy-Authorization , que es la representación Base64 del username:password 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 ¿verdad?
5. El cliente vuelve a intentar la solicitud con un encabezado de Proxy-Authorization y un encabezado de Authorization valuado con la representación Base64 del username:password de username:password de la aplicación username:password .
6. En este punto, el proxy autentica con éxito la solicitud y reenvía la solicitud a la aplicación que también autentica 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 intermedio recuperaría un mensaje 407 Proxy Authentication Required y se repetirá la solicitud con el encabezado Proxy-Authorization ; los encabezados Proxy-Authenticate y Proxy-Authorization son encabezados de un solo salto que no pasan de un servidor a otro, pero WWW-Authenticate y Authorization son encabezados de extremo a extremo que se consideran del cliente al final. servidor, pasado literalmente por los intermediarios.

Dado que el esquema Basic envía la contraseña en forma clara (base64 es una codificación reversible), se usa con mayor frecuencia a través de SSL. Este escenario se implementa de una manera diferente, porque es deseable evitar que el proxy vea la contraseña enviada al servidor final:

• el cliente abre un canal SSL al proxy para iniciar la solicitud, pero en lugar de enviar una solicitud HTTP regular, enviará una solicitud especial CONNECT (aún con un encabezado Proxy-Authorization ) para abrir un túnel TCP al servidor remoto.
• Luego, el cliente procede a crear otro canal SSL anidado dentro del primero, sobre el cual transfiere el mensaje HTTP final, incluido 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.