Aug 13, 2009

HTTP authentication on redirect

I recently had a hard way understanding Http authentication particularly involving redirect. After googling and conversing with a good friend, Alan, here is the picture on what will happen when server A (or browser)makes a http request to server B which redirects to server C:

  • Server A: Request.Credentials = CredentialCache.DefaultCredentials Sent request to Sever B
  • Server B: returns 401 – List of login schemes supported From Secured web page
  • Server A: Sends Request + Request.Credentials (formatted according to the selected login scheme) to Server B
  • Server B: returns 302 – "Redirect to Server C"
  • Server A: Request sent again to Server C
  • Server C: return 401 – List of login methods supported From New secured web page
  • Server A: Request + Request.Credentials (formatted according to the selected login scheme) to Server C
  • Server C: returns 200 – Content From New secured web page

Why auth handshake always happen even if the credential is set? This is by design, because Httprequest clients have no idea what auth schema the remote server is using. You can avoid first auth handshake by manually setting HttpRequest's header, like: req.Headers.Add("Authorization", "basic " + base64); But this needs to be done every time even for same Uri-Pref. Generally allowing handshake and setting PreAuthentication=true is better. See this post for details.

When making HttpRequest, HttpRequest object need to have a CookierContainer, which will be used by HttpResponse to fill in. It doesn't do anything with authentication though.

Another thing related is, in case of impersonating, Kerberos (both authentication and delegation) is required in order to forward default credentials (double hoppings).