Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

HTTP Spec: Proxy-Authorization and Authorization headers

So I'm trying to implement the following scenario:

  • An application is protected by Basic Authentication. Let's say it is hosted on app.com
  • An HTTP proxy, in front of the application, requires authentication as well. It is hosted on 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:

  1. The user makes an HTTP request to the proxy without any sort of authentication.
  2. The proxy answers 407 Proxy Authentication Required and returns a Proxy-Authenticate header in the format of: "Proxy-Authenticate: Basic realm="proxy.com".
    Question: Is this Proxy-Authenticate header correctly set?
  3. The client then retries the request with a Proxy-Authorization header, that is the Base64 representation of the proxy username:password.
  4. This time the proxy authenticates the request, but then the application answers with a 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?
  5. The client retries again the request with both a Proxy-Authorization header, and a Authorization header valued with the Base64 representation of the app's username:password.
  6. At this point, the proxy successfully authenticates the request, forwards the request to the application that authenticates the user as well. And the client finally gets a response back.

Is the whole workflow correct?

like image 817
Mark Avatar asked Apr 05 '12 06:04

Mark


People also ask

What is HTTP Authorization header?

The HTTP Authorization request header can be used to provide credentials that authenticate a user agent with a server, allowing access to a protected resource. The Authorization header is usually, but not always, sent after the user agent first attempts to request a protected resource without credentials.

In which section the proxy Authorization headers are indicated?

The related HTTP Status Code for the HTTP Header is “407” which means “Proxy-Authentication Required”, an example is shown below. Proxy-Authenticate HTTP Response Header can be seen above within the “407” code.

What is basic proxy authentication?

Proxy Authentication enables you to configure the authentication method used by the proxy. This determines how client machines are validated when accessing the Internet. Proxy Authentication must be enabled to be able to create new policies for users or groups. By default, Proxy Authentication is disabled.

How do I send HTTP request with Authorization header?

To send a request with the Bearer Token authorization header, you need to make an HTTP request and provide your Bearer Token with the "Authorization: Bearer {token}" header. A Bearer Token is a cryptic string typically generated by the server in response to a login request.


1 Answers

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:

  • the client opens an SSL channel to the proxy to initiate the request, but instead of submitting a regular HTTP request it would submit a special CONNECT request (still with a Proxy-Authorization header) to open a TCP tunnel to the remote server.
  • The client then proceeds to create another SSL channel nested inside the first, over which it transfers the final HTTP message including the 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.

like image 87
Martin Atkins Avatar answered Oct 02 '22 20:10

Martin Atkins