¿Cómo puedo implementar la autenticación en mi servidor proxy?

Por lo general, la forma estándar de implementar la autenticación proxy es, sorprendentemente, Autenticación de proxy .
Este es un conjunto de respuestas y request headers, que juntos implementan la autenticación que se requiere entre el usuario y el proxy.

Esto se usa comúnmente con proxies transparentes, y está bien soportado tanto en los navegadores como en los proxies. Algunos proxies implementan esto de manera diferente (por ejemplo, cómo se verifican las credenciales), pero en la mayoría de los casos esta es la solución más preferida. Hay muy pocos inconvenientes a esta solución, y las soluciones alternativas que rompen el estándar HTTP, como BlueCoat, tienen bastante algunos problemas

Ahora, sí mencionas que tu proxy implementará un portal cautivo, pero no mencionaste por qué . Si solo se trata de implementar el formulario de autenticación, pensando que no hay una solución integrada, le recomendaría cambiar su solución, usar proxies estándar y simplemente definir la autenticación requerida. Crear tu propio portal cautivo es demasiado complicado, y es probable que te abra un montón de vulnerabilidades (por experiencia).
Si hay alguna otra razón para crear el portal cautivo (registros aleatorios, opciones de pago, diversión loca, etc.), tal vez sea más complejo, y podemos lidiar con ellos. De lo contrario, se parece a un problema XY (donde asume una solución y pregunta sobre eso, en lugar de preguntar por su problema actual ...)

BlueCoat cuando se implementa como un proxy transparente puede usar el concepto de sustitutos de cookies para autenticar a un usuario, para que funcione, el mecanismo central utilizado es la redirección a una URL virtual que siempre solicitará autenticación (HTTP 401), aquí está cómo se implementa en él:

Autenticación por primera vez:
1. UA (agente de usuario) emite un GET / a HOST:www.example.com
2. El servidor proxy intercepta el GET y responde con una redirección (302) a la URL virtual y una cadena de consulta que contiene la URL original solicitada, por ejemplo. " http://virtualURL.com?QueryString "
3. UA intenta conectarse a una URL virtual
4. El proxy responde con HTTP 401, solicitando autenticación
5. UA vuelve a emitir la misma solicitud del paso 3, pero con credenciales de autenticación
6. La UA se redirige de nuevo (302), esta vez a la URL original, la cadena de consulta aún se adjunta a esta redirección ( http://www.example.com?QueryString ), también hay un SET-COOKIE que parece provenir de virtualURL (se usará en solicitudes a sitios distintos al inicial)
7. UA se conecta a la URL original + Cadena de consulta, ya que aún tiene la Cadena de consulta en la solicitud que el proxy emite un nuevo 302, esta vez a www.example.com , también incluye un SET-COOKIE , pero esta vez la cookie se comporta como se emite desde el dominio example.com.
8. UA se conecta a www.example.com , la cookie también se recibe y acepta. Esta cookie notifica al proxy que el usuario está autenticado.
9. El proxy reenvía la solicitud de UA a la URL original que elimina la cookie, para no interferir con la transacción.

Las solicitudes subsiguientes seguirán como:

La solicitud a www.newsite.com , se redirige a virtualURL?QueryString , esta vez ya existe una cookie para el dominio virtualURL, por lo que no se necesita 401, la nueva redirección a newsite.com?QueryString , SET-COOKIE para el nuevo dominio, la redirección a URL original.

Supongo que utilizando el mismo concepto puede adaptarlo a su servidor proxy.