HTTP, an application level protocol for distributed hypermedia systems, came into existence in 1990 with HTTP/0.9, a simple protocol for raw data transfer over the Internet.
With HTTP 1.x came a built-in mechanism for authentication, fully documented in RFC 2617. HTTP 1.1 supports two modes of bulit-in authentication "Basic" and "Digest". Basic authentication transmits the username/password pair in unencrypted form from browser to server. It should only be used over an encrypted medium e.g. SSL (Secure Sockets Layer recently renamed by the IETF to TLS, or Transport Layer Security). Digest authentication sends a one-way hash of the username/password pair, calculated with a time-sensitive salt value from the server. The purpose of the salt value is that the username-password hash is always unique, and protected from replay attacks. Note though that only the authentication details are protected by the hash and any data sent following successful authentication will be visible to any party with access to the network traffic. To overcome this, an encrypted stream is needed.
Attempting to retrieve a page using HTTP authentication can result in an HTTP 401 (Unauthorized) error (some other interesting error codes are listed here, including the currently unused 402 error - Payment Required). The response from the server will include a "WWW-authenticate" header of the form (WWW-Authenticate: AUTH_SCHEME realm="REALM_NAME"). A valid value for AUTH_SCHEME would be Basic, to denote basic authentication. The "realm" is the section of the website protected by the authentication scheme. Since HTTP is stateless, servers don't remember who is logged in and clients must send correct headers for each protected page they wish to access.
IIS provides substatus codes to analyse the underlying causes of 401 errors. The codes are: 1) invalid credentials, 2) wrong authentication method, 3) ACL issue, 4) ISAPI (Internet Server API)/CGI issue, and, 5) access denied by URL authorization policy on server.
No comments:
Post a Comment