HTTP Spec: Proxy-autorizzazione e di autorizzazione intestazioni

Question

Così sto cercando di implementare il seguente scenario:

• Un'applicazione è protetta da autenticazione di base. Diciamo che è ospitato su app.com
• Un proxy HTTP, di fronte all'applicazione, richiede anche l'autenticazione. Esso è presente in proxy.com

L'utilizzatore deve quindi fornire le credenziali sia per il proxy e l'applicazione nella stessa richiesta, così ha diverse coppie nome utente/password: una coppia di autenticarsi contro l'applicazione, e un altro nome utente/password per autenticarsi contro il proxy.

Dopo aver letto le specifiche, non sono molto sicuro su come dovrei implementarlo. Quello che stavo pensando di fare è:

1. L'utente effettua una richiesta HTTP al proxy senza alcun tipo di autenticazione.
2. Il proxy risponde a 407 Proxy Authentication Required e restituisce un'intestazione Proxy-Authenticate nel formato di: "Proxy-Authenticate: Basic realm="proxy.com".
   Domanda: L'intestazione Proxy-Authenticate è impostata correttamente?
3. Il client riprova la richiesta con un'intestazione Proxy-Authorization, ovvero la rappresentazione Base64 del proxy username:password.
4. Questa volta il proxy autentica la richiesta, ma poi l'applicazione risponde con un'intestazione 401 Unauthorized. L'utente è stato autenticato dal proxy, ma non dall'applicazione. L'applicazione aggiunge un'intestazione WWW-Authenticate alla risposta come WWW-Authenticate: Basic realm="app.com". Domanda: questo valore di intestazione è corretto vero?
5. Il client riprova la richiesta con un'intestazione Proxy-Authorization e un'intestazione Authorization valutata con la rappresentazione Base64 dell'app username:password.
6. A questo punto, il proxy autentica correttamente la richiesta, inoltra la richiesta all'applicazione che autentica anche l'utente. E il cliente ottiene finalmente una risposta.

L'intero flusso di lavoro è corretto?

Answer 1

Sì, sembra un flusso di lavoro valido per la situazione descritta e quelle intestazioni Autentiche sembrano essere nel formato corretto.

È interessante notare che è possibile, anche se improbabile, che una determinata connessione coinvolga più proxy che sono concatenati insieme e ognuno di essi può richiedere un'autenticazione. In questo caso, il lato client di ciascun proxy intermedio ritroverà automaticamente un messaggio 407 Proxy Authentication Required e ripeterà la richiesta con l'intestazione Proxy-Authorization; le intestazioni Proxy-Authenticate e Proxy-Authorization sono intestazioni single-hop che non vengono passate da un server all'altro, ma WWW-Authenticate e Authorization sono intestazioni end-to-end considerate dal client al server finale, passate letteralmente da gli intermediari.

Poiché lo schema Basic invia la password in chiaro (base64 è una codifica reversibile) è più comunemente utilizzato su SSL.Questo scenario è implementata in modo diverso, perché è opportuno evitare che il proxy di vedere la password inviata al server finale:

• il client apre un canale SSL per il proxy per avviare la richiesta, ma invece di inviando una richiesta HTTP regolare, invierà a special CONNECT request (sempre con l'intestazione Proxy-Authorization) per aprire un tunnel TCP sul server remoto.
• Il client quindi continua a creare un altro canale SSL nidificato all'interno del primo, su cui viene trasferito il messaggio HTTP finale compresa l'intestazione Authorization.

In questo scenario il proxy conosce solo l'host e la porta a cui è connesso il client, non ciò che è stato trasmesso o ricevuto sul canale SSL interno. Inoltre, l'uso di canali nidificati consente al client di "vedere" i certificati SSL sia del proxy che del server, consentendo l'autenticazione di entrambi.