Basic Protection Scheme

1. (Server sends an Unauthorized status).
2. Client authenticates himself.
3. Server checks authentication and authorization.
4. If previous was step successful, document is sent normally by the server.
5. Document is recieved normally by the client. If the server protection hierarchy is clear and the browser sophisticated enough to figure out right away if a document is protected, first step is visited very seldom (possibly only once) during the entire browsing session for each protected server.

   Step 1: Server Sends an Unauthorized Status

   Once a server receives a request without an Authorization: field to access a document that is protected, it sends an Unauthorized 401 status code, and a set of WWW-Authenticate: fields containing valid authentication schemes and their scheme-specific parameters.

   In Basic scheme the reply is following:

           HTTP/1.0 401 Unauthorized -- authentication failed
           WWW-Authenticate: Basic realm="CollabName"
   

   where realm specifies used password file; same server can use different password file for different trees of documents (this is the server-id specified in CERN server protection setup file). Client can thus figure out which password to use at any given time.

   Step 2: Client Authenticates Himself

   After receiving Unauthorized status code, the browser prompts for user name and password (if they are not already given by the user), and constructs a string containing those two separated by a colon:

           username:password
   

   This string is then encoded into printable characters, and sent it along with the next request in the Authorization: field as follows:

           Authorization: Basic encoded_string
   

   Step 3: Server Checks Authentication and Authorization

   When the server receives a request to access a document protected by the Basic Scheme, and the request is a full request containing Authorization: field which contains the Basic Scheme information, it will execute the following Access Request Validation Procedure:
   1. The server receives an Authorization: field with the scheme name Basic and encoded authorization string.
   2. If the scheme name is wrong, access is denied, and an Unauthorized 401 status with WWW-Authenticate: field containing appropriate scheme name (Basic) and realm name is sent back (as if no authorization information was given).
   3. If scheme name is correct the authorization string is decoded.
   4. If the access information is correct, the result should have two fields separated by a colon, of which at least the first must be non-empty (there can be a username without a password).
   5. If not, access is denied, and an Unauthorized 401 status with appropriate WWW-Authenticate: field is sent back.
   6. Otherwise, username and password are checked for validity from the password file.
   7. If the username-password pair is incorrect, access is denied with an Unauthorized 401 status and WWW-Authenticate: field etc.
   8. If the username-password pair is correct, the server checks if user and connecting IP address are members of mask-group (if) specified in protection setup file (using group file).
   9. Server then looks for an entry for the requested file in the corresponding Access Control List File, which is in the same directory as the file to be accessed, named .www_acl (if any).
   10. If there is no mask-group nor ACL, or if ACL exists, but there is no entry for that file, access is denied with a Frobidden 403 status code.
   11. If there is an ACL entry for it, server checks if the user and connecting IP address belong to the list of groups and users allowed to access it (using group file).
   12. If not, an Unauthorized 401 status etc. is sent.
   13. Otherwise, the server checks if the requested file exists.
   14. If not, a Not found 404 status is sent back.
   15. Otherwise access is allowed, and the server sends the document normally to the browser.

   See also the discussion about Basic Protection Scheme.

   AL 12 December 1993