Come posso implementare l'autenticazione nel mio server proxy?

In genere, il modo standard per implementare l'autenticazione proxy è, a sorpresa, Autenticazione proxy .
Questo è un insieme di corrispondenza risposta e request intestazioni, che insieme implementano l'autenticazione richiesta tra l'utente e il proxy.

Questo è comunemente usato con proxy trasparenti ed è ben supportato in entrambi i browser e proxy. Alcuni proxy lo implementano in modo diverso (ad esempio, come vengono verificate le credenziali), ma nella maggior parte dei casi questa è la soluzione più preferita. Ci sono pochissimi inconvenienti a questa soluzione e soluzioni alternative che interrompono il protocollo HTTP standard, come BlueCoat, hanno abbastanza pochi problemi.

Ora fai riferimento al fatto che il tuo proxy implementerà un captive portal, ma non hai menzionato perché . Se è solo per implementare il modulo di autenticazione, pensando che non esiste una soluzione integrata, ti consiglio di cambiare la soluzione, utilizzare i proxy standard e solo definire l'autenticazione richiesta. Costruire il proprio captive portal è troppo complicato e probabilmente ti aprirà a un gran numero di vulnerabilità (dall'esperienza).
Se c'è qualche altra ragione per costruire il captive portal - iscrizioni casuali, opzioni di pagamento, divertimento pazzesco, ecc. - forse elaborate, e possiamo gestirle. Altrimenti somiglia a un problema XY (dove presumi una soluzione e chiedi spiegazioni, invece di chiedere del tuo problema reale ...)

BlueCoat quando distribuito come proxy trasparente può utilizzare il concetto di surrogati dei cookie per autenticare un utente, per farlo funzionare il meccanismo di base utilizzato è il reindirizzamento a un URL virtuale che richiederà sempre l'autenticazione (HTTP 401), ecco come è implementato su di esso:

Prima autenticazione:
1. UA (agente utente) emette un GET / in HOST:www.example.com
2. Il server proxy intercetta il GET e risponde con un reindirizzamento (302) all'URL virtuale e una stringa di query che contiene l'URL originale richiesto, ad es. " http://virtualURL.com?QueryString "
3. UA tenta di connettersi all'URL virtuale
4. Il proxy risponde con HTTP 401, richiedendo l'autenticazione
5. UA riemette la stessa richiesta del passaggio 3, ma con le credenziali di autenticazione
6. UA viene nuovamente reindirizzato (302), questa volta all'URL originale, la stringa di query è ancora collegata a questo reindirizzamento ( http://www.example.com?QueryString ), inoltre c'è un SET-COOKIE che sembra provenire da virtualURL (verrà utilizzato su richieste a siti diversi da quello iniziale)
7. UA si collega all'URL originale + stringa di query, poiché ha ancora la stringa di query sulla richiesta che il proxy emette un nuovo 302, questa volta a www.example.com , include anche un SET-COOKIE , ma questa volta il cookie si comporta come emesso dal dominio example.com.
8. UA si connette a www.example.com , il cookie viene anche ricevuto e accettato. Questo cookie notifica al proxy che l'utente è autenticato.
9. Il proxy inoltra la richiesta UA all'URL originale rimuovendo il cookie, per non interferire con la transazione.

Le richieste successive seguiranno come:

Richiesta di www.newsite.com , reindirizzati a virtualURL?QueryString , questa volta esiste già un cookie per il dominio virtualURL, quindi non è necessario un 401, nuovo reindirizzamento a newsite.com?QueryString , SET-COOKIE per nuovo dominio, reindirizzamento a URL originale.

Immagino che usando lo stesso concetto puoi adattarlo al tuo server proxy.