So I'm trying to implement the following scenario:
app.com
proxy.com
The user must therefore provide credentials for both the proxy and the application in the same request, thus he has different username/password pairs: one pair to authenticate himself against the application, and another username/password pair to authenticate himself against the proxy.
After reading the specs, I'm not really sure on how I should implement this. What I was thinking to do is:
407 Proxy Authentication Required
and returns a Proxy-Authenticate
header in the format of: "Proxy-Authenticate: Basic realm="proxy.com"
.Proxy-Authenticate
header correctly set?Proxy-Authorization
header, that is the Base64 representation of the proxy username:password
.401 Unauthorized
header. The user was authenticated by the proxy, but not by the application. The application adds a WWW-Authenticate
header to the response like WWW-Authenticate: Basic realm="app.com"
. Question: this header value is correct right?Proxy-Authorization
header, and a Authorization
header valued with the Base64 representation of the app's username:password
.Is the whole workflow correct?
Yes, that looks like a valid workflow for the situation you described, and those Authenticate headers seem to be in the correct format.
It's interesting to note that it's possible, albeit unlikely, for a given connection to involve multiple proxies that are chained together, and each one can itself require authentication. In this case, the client side of each intermediate proxy would itself get back a 407 Proxy Authentication Required
message and itself repeat the request with the Proxy-Authorization
header; the Proxy-Authenticate
and Proxy-Authorization
headers are single-hop headers that do not get passed from one server to the next, but WWW-Authenticate
and Authorization
are end-to-end headers that are considered to be from the client to the final server, passed through verbatim by the intermediaries.
Since the Basic
scheme sends the password in the clear (base64 is a reversible encoding) it is most commonly used over SSL. This scenario is implemented in a different fashion, because it is desirable to prevent the proxy from seeing the password sent to the final server:
CONNECT
request (still with a Proxy-Authorization
header) to open a TCP tunnel to the remote server.Authorization
header.In this scenario the proxy only knows the host and port the client connected to, not what was transmitted or received over the inner SSL channel. Further, the use of nested channels allows the client to "see" the SSL certificates of both the proxy and the server, allowing the identity of both to be authenticated.