BlueCoat when deployed as a transparent proxy can use the concept of cookie surrogates to authenticate a user, in order to make it work the core mechanism used is the redirection to a virtual URL that will always request authentication (HTTP 401), here's how it's implemented on it:
First time authentication:
1. UA (User agent) issues a
GET / to
2. Proxy server intercepts the GET and replies with a redirect (302) to the virtual URL and a query string that contains the original URL requested, e.g. "
3. UA attempts to connect to virtual URL
4. Proxy replies with HTTP 401, requesting authentication
5. UA reissues the same request of step 3, but with authentication credentials
6. UA is redirected again (302), this time to the original URL, the query string is still attached to this redirect (
http://www.example.com?QueryString), also there's a
SET-COOKIE that appears to be coming from virtualURL (this will be used on requests to sites other than the initial one)
7. UA connects to the original URL + Query string, since it still have the Query String on the request the proxy issues a new 302, this time to
www.example.com, also includes a
SET-COOKIE, but this time the cookie behaves as being issued from example.com domain.
8. UA connects to
www.example.com, the cookie is also received and accepted. This cookie notifies the proxy that the user is authenticated.
9. The proxy forwards the UA request to the original URL removing the cookie, to not interfere with the transaction.
Subsequent requests will follow as:
www.newsite.com, get redirected to
virtualURL?QueryString, this time there already is a cookie to the virtualURL domain, so no 401 is needed, new redirect to
SET-COOKIE for new domain, redirect to original URL.
I guess that using the same concept you can adapt it to your proxy server.