Using User Authentication: Creating A User Database
Using User Authentication: Creating A User Database
There are two ways of restricting access to documents: either by the hostname of the browser being used, or by asking for a username and password. The former can be used to, for example, restrict documents to use within a company. However if the people who are allowed to access the documents are widely dispersed, or the server administrator needs to be able to control access on an individual basis, it is possible to require a username and password before being allowed access to a document. This is called user authentication. Setting up user authentication takes two steps: firstly, you create a file containing the usernames and passwords. Secondly, you tell the server what resources are to be protected and which users are allowed (after entering a valid password) to access them.
Using htpasswd
To create a new user file and add the username "martin" with the password "hampster" to the file /usr/local/etc/httpd/users: htpasswd -c /usr/local/etc/httpd/users martin The -c argument tells htpasswd to create new users file. When you run this command, you will be prompted to enter a password for martin, and confirm it by entering it again. Other users can be added to the existing file in the same way, except that the -c argument is not needed. The same command can also be used to modify the password of an existing user. After adding a few users, the /usr/local/etc/httpd/users file might look like this: martin:WrU808BHQai36 jane:iABCQFQs40E8M art:FAdHN3W753sSU
The first field is the username, and the second field is the encrypted password.
Using Groups
If you want to allow only selected users from the users file in to a particular area, you can list all the allowed usernames on the require line. However this means you are building username information into your .htaccess files, and might not been convenient if there are a lot of users, and . Fortunately there is a way round this, using a
group file. This operates in a similar way to standard Unix groups: any particular user can be a member of any number of groups. You can then use the require line to restrict users to one or more particular groups. For example, you could create a group called staff containing users who are allowed to access internal pages. To restrict access to just users in the staff group, you would use require group staff Multiple groups can be listed, and require user can also be given, in which case any user in any of the listed groups, or any user listed explicitly, can access the resource. For example require group staff admin require user adminuser which would allow any user in group staff or group admin, or the user adminuser, to access this resource after entering a valid password. A group file consists of lines giving a group name followed by a space-separated list of users in that group. For example: staff:martin jane admin:art adminuser The AuthGroupFile directive is used to tell the server the location of the group file. Note that the maximum line length within the group file in about 8000 characters (actually 8kB). If you have more users in a group than will fit within that line length, you can have more than one line with the same group name within the file.
The server checks the username and password, and if they are valid, returns the page. If the password is not valid for that user, or the user is not allowed access because they are not listed on a require user line or in a suitable group, the server returns a 401 status as before. The browser can then ask the user to retry their username and password. Assuming the username and password was valid, the user might next request another resource which is protected. In this case, the server would respond with a 401 status, and the browser could send the request again with the user and password details. However this would be slow, so instead the browser sends the Authorization header on subsequent requests. Note that the browser must ensure that it only sends the username and password to further requests on the same server (it would be insecure to send those details if the user moved onto a different server). The browser needs to remember the username and password entered, so it can send them with future requests from the same server. Note that this can cause problems when testing authentication, since the browser remembers the first username and password that works. It can be difficult to force the browser to ask for a new username and password.
The Digest Authentication scheme will make the sending of passwords across the Internet more secure. It effectively encrypts the password before it is sent such that the server can decrypt it. It works exactly the same as Basic authentication as far as the end-user and server administrator is concerned. The use of Digest authentication will depend on whether browser authors write it into their products. Apache can already do Digest authentication, when compiled with the mod_digest module (supplied with the Apache distribution).
More Information
For more information about how user authentication works on the Internet, see the HTTP/1.0 and HTTP/1.1 documents, available from the Apache Week links page. Also available there is a link to the draft Digest Authentication specification. For basic information about setting up user authentication, see the NCSA Tutorial (most of which also applies to Apache). For modules which allow usernames, groups and passwords to be stored in database format files, or databases themselves, see this Apache Week feature on Adding Modules.