2.6 Server configuration

Based on the HTTP basic and digest access authentication schemes overviewed in the previous sections, Web server software packages usually provide support for user -based and group -based authorization and access control. For example, the Apache server allows an administrator to define authorized users, give them passwords, and place them in groups similar to the UNIX operating system. The syntax that is used to specify access control rules heavily depends on the Web server software in use. You may refer to the manual of your server software package for a description of the syntax that must be used. In the examples that follow, we refer to the Apache Web server software that is widely deployed today. Further information can be found at http://httpd.apache.org/docs/howto/auth.html.

2.6.1    Configuring HTTP basic authentication

To protect the contents of an Apache Web server with the HTTP basic authentication scheme, the following two configuration steps must be completed:

1. A password file must be created. The file must include the names and encrypted passwords of the legitimate and authorized users of the server. Because the file contains sensitive information, it should be stored outside of the document tree. To create and manage the password file, a utility called htpasswd may be used. ^[15] This utility creates entries that look as follows (for username rolf and password test ):

   rolf:yIvSBWSuLs2N2

   Obviously, the first field includes the username (i.e., rolf ) and the second field includes the encrypted password (i.e., yIvSBWSuLs2N2 ). The password is encrypted using the standard UNIX password encryption function [i.e., crypt() ]. This basically means that the zero-string is encrypted using the password as a key, that a modified and slowed-down version of the DES serves as encryption algorithm, that an additional 12-bit value (i.e., a so-called salt) is used to seed the encryption, and that each encrypted password is Base-64-encoded as 13 printable characters (the first two characters representing the salt). Due to the salt mechanism, the password encryption function is nondeterministic, meaning that two users who have randomly chosen the same password may end up having encrypted passwords that look completely different. For example, 8DPEnfGmhy3f. , oC.DJuDdSwd4w, and N.Ecp9ZAWAPXE are all valid and equivalent encodings of the username rolf and the encrypted password test (i.e., they all use different salt values). Optionally, a group file may be created to define that certain users belong together and may be treated as a group ( mainly to simplify user management). Each group is defined by a group name and a list of members (i.e., users). For example:

   family: isabelle marc lara rolf

   In this case, a group named family is defined to include the members isabelle, marc, lara, and rolf. Note that for each of these members an entry in the password file must exist.

2. The use of the password and group files must be configured on the server side. There are a number of server directives that can be used for this purpose:

   • The AuthType directive is used to specify the authentication type being used (i.e., Basic or Digest ).

   • The AuthName directive is used to specify the authentication realm or name.

   • The AuthUserFile directive is used to specify the location of the password file.

   • The AuthGroupFile directive is used to specify the location of the group file, if any.

   • The Require directive is used to specify the requirement(s) that must be satisfied in order to grant admission.

   The directives can be placed in a .htaccess file in the particular directory being protected, or may go in a < Directory > section of the server s access configuration file (i.e., access.conf). To allow a directory to be restricted within an .htaccess file, however, the access.conf file must allow user authentication and authorization to be set up in .htaccess files. This is controlled by the AuthCong override. More specifically , the access.conf file must include AllowOverride AuthCong to allow user authentication and authorization in .htaccess files. In the explanations that follow, we assume the AuthCong override is included in theWeb server s access configuration file.

Let s have a look at the server configuration that is used to protect the directory /Demo/HTTPBasicAuthentication at www.esecurity.ch. Protection is invoked by placing the following .htaccess file in the protected directory:

 AuthType Basic AuthName "HTTP Basic Authentication Demo" AuthUserFile /home/esecurity.ch/conf/passwords AuthGroupFile /home/esecurity.ch/conf/groups require valid-user 

Obviously, the first line indicates the use of the HTTP basic authentication-scheme. The second line specifies the realm string that is used in the prompt to request the user to enter his or her password (this is illustrated in Figures 2.1 and 2.2). The third and fourth lines specify the location of the password and group files. Finally, the fifth line requires that any user provides his or her valid password to get access (in this case, the group file is not used at all). This part could be expanded to limit access to specific users or groups or specific access methods (e.g., GET). For example:

 <LIMIT GET>   require group family </LIMIT> 

limits user access to the members of the family group employing the HTTP GET method (in this case, the group file is used). In general, a < Limit > section is established between the < Limit > and < /Limit > directives. It can be used to establish an access control policy for the directory. The format is < Limit X Y ... >, where each of the parameters is one of the HTTP access methods (e.g., GET, POST, PUT, or DELETE). Browsers that try to use one of the listed methods are restricted according to the rules listed within the section. If no method is listed, the restrictions apply to all methods. Multiple groups may be listed and multiple require directives may be used.

Using the htpasswd utility to create and manage a list of users in a password file, and maintaining a list of groups in a corresponding group file, is a relatively simple task. However, if the number of users becomes large, the server has a lot of processing to do in finding a user s authentication information. In fact, the server has to open the password file, look through it one line at a time until it finds the user that is trying to log in, and verify the password. In the worst case, if the username supplied is not there at all, every line in the file will need to be checked. On average, half of the file will need to be read before the user is found. To make things worse , this processing must be done for every request to access the protected realm (even though the user only enters his or her password once, the server has to reauthenticate on every request). This can be slow with a lot of users, and adds to the Web server load. Much faster access is possible using a database system. In the case of the Apache Web server, there are several database modules that may be used (e.g., mod_auth_db and mod_auth_dbm). The corresponding directives may change (e.g., AuthDBUserFile instead of AuthUserFile in the case of using Berkeley DB files and HTTP basic authentication) but the principle ideas remain the same. It is also possible to have an arbitrary external program check whether the given username and password are valid (this could be used to write an interface to check against any other database or authentication service). Modules are also available to check against the system password file or ”more interestingly ”to use a Kerberos authentication system.

2.6.2    Configuring HTTP digest access authentication

To protect the contents of an Apache Web server with the HTTP digest access authentication scheme, the following two configuration steps must be completed:

1. A password file must be created. For every legitimate and authorized user, the file must include the username, the realm string, and the user password in possibly encrypted form. Again, the file contains sensitive information and should be stored outside of the document tree. To create and manage the password file, a utility called htdigest can be used. ^[16] It creates entries like

   rolf:HTTP Digest Access Authentication Demo:672203b528e0-c29e08df53cba3f51b66

   for the username rolf, the realm string ˜ ˜HTTP Digest Access Authentication Demo, and the password test. Note that the username and the realm string are not encrypted, and that the password is the only value that is encrypted. Contrary to the password encryption routine employed by the .htpasswd utility, however, the password encryption routine employed by the .htpasswd utility is deterministic, meaning that no salt is used, and that the same password is always encrypted and encoded to the same value (i.e., 672203b528e0c29e08df53cba3f51b66 in the example above). Optionally, a group file can be created to simplify user management. The syntax of the file is the same as the one employed by the HTTP basic authentication scheme.

2. The use of the password and group files must be configured on the server side. In addition to the directives that are available for the HTTP basic authentication scheme (i.e., AuthType , AuthName , and Require ), the following two directives may be used to configure the use of the HTTP digest access authentication scheme:

   • The AuthDigestFile directive is used to specify the location of the password file.

   • The AuthDigestGroupFile directive is used to specify the location of the group file (if any).

   The placement of the directives is identical to the HTTP basic authentication scheme.

For example, the following .htaccess file may be used to protect the directory /Demo/HTTPBasicAuthentication at www.esecurity.ch:

 AuthType Digest AuthName "HTTP Digest Access Authentication Demo" AuthDigestFile /home/esecurity.ch/conf/digests AuthDigestGroupFile /home/esecurity.ch/conf/groups require valid-user 

The semantics of the directives should be clear. Again, access to the protected directory may be restricted to specific HTTP access methods (e.g., GET) using the < Limit > and < /Limit > directives.

^[15] The htpasswd utility is typically located in the bin directory of the Apache installation.

^[16] Similar to the htpasswd utility, the htdigest utulity is typically located in the bin directory of the Apache installation.