1

I am using .htaccess authentication for my website. Once the authentication happen with AD vi LDAP, how the authenticated user's session and cookies got created in the browser and where the redirection is really happening to my website. Please help in this or please share any links which explains this process.

SivaTheSpider
  • 41
  • 1
  • 3
  • HTTP Authentication doesn't use cookies. The browser will always send the authorization header until it's restarted. – Jon Lin Jun 29 '12 at 15:53
  • Thanks for your inputs Jon. I want to learn something more on it, can you please share any link or wiki for the same. Is it something like for each page request the server will send the authorization response headers to the client(Browser) ? – SivaTheSpider Jun 30 '12 at 16:55

1 Answers1

1

Take a look at the wiki pages for BASIC authentication and DIGEST authentication, both is an authentication mechanism that is on the protocol (HTTP). Basically, this is what the browser sees (heavily paraphrasing here):

  1. Attempt to request a URI, webserver replies with a 401 response and a WWW-Authenticate header
  2. This header contains a REALM, kind of like a group of pages that all belong to the same authentication realm
  3. Browser pops up a modal dialog box asking for a username and password.
  4. Depending on BASIC or DIGEST, that password is sent back to the webserver along with the original request that resulted in a 401.
  5. If the credentials are incorrect, a 403 is returned and the browser shows an appropriate error message. Otherwise, the webserver returns the requested page.
  6. The browser knows this URL belongs to the REALM, so every time this URL is requested, authorization is automatically sent along with the request.
  7. If the browser requests something else that also requires authentication, and it belongs to the same REALM, the browser will automatically send the authorization when the webserver returns a 401 and the REALM.

How the webserver is configured with REALM info and a list of credentials varies. It could be hooked up to a LDAP database, Active directory, a flat file with hashed passwords, etc.

This is different than cookies or other webapp-level authentication because it doesn't use the HTTP protocol to authenticate. The webapp has a page with forms for a username and password, those are sent via a POST/GET request as parameters, and it's up to the webapp to determine if those credentials are valid. If they are valid, the webapp could choose to store a session ID as a cookie so the browser can continue to browse pages served by the webapp.

One of the end-user differences between this and HTTP authentication is that the webapp can delete the cookie, or invalidate that session, essentially logging the user out of the webapp. This isn't really possible with HTTP authentication because the browser blindly submits an authorization header when requesting pages under the same REALM. One way to get around this is to make the webserver forcefully return a 403 when a protected page is requested.

Another difference is that with HTTP authentication, you can include a username/password as part of the URL. How does http://user:pass@host.com authentication work?

Also see: http://blog.distributedmatter.net/post/2008/06/09/HTTP-authentication-mechanisms-and-how-they-could-work-in-Restlet for a more complete description of authentication in general.

Community
  • 1
  • 1
Jon Lin
  • 142,182
  • 29
  • 220
  • 220