Mosaic 2.0 and NCSA HTTPd allow access restriction based on several criteria:
NCSA HTTPd 1.5 has support for HTTP Basic Authentication (Basic), as well as the proposed Message Digest Authentication (MD5). Most, if not all, current browsers should support HTTP Basic Authentication, but not all browsers support MD5. Some browsers that do include NCSA Mosaic/X 2.7 and Spyglass Mosaic
Per-directory configuration means that users with write access to part of the filesystem that is being served (the Document Tree) can control access to their files as they wish. They need not have root access on the system or write access to the server's primary configuration files. Also, the per-directory configuration files are read and parsed by the server on each access, allowing run-time re-configuration. The global configuration files are only parsed on start-up or restart, which usually requires root authority. There is a speed penalty associated with using the per-directory configuration files, but that's the trade-off you have to take.
Access control for a given directory is controlled by a specific file
in the directory with a filename as specified by the
directive. The default filename is
So basically this method of authentication is roughly as safe as
telnet-style username and password security -- if you
trust your machine to be on the Internet, open to attempts to
telnet in by anyone who wants to try, then you have no
reason not to trust this method also.
In MD5 Message Digest Authentication, the password is not passed over
the network at all. Instead, a series of numbers is generated based
on the password and other information about the request, and these
numbers are then hashed using MD5. The resulting "digest" is then sent
over the network, and it is combined with other items on the server to
test against the saved digest on the server. This method is more secure
over the network, but it has a penalty. The comparison digest on the
server must be stored in a fashion that it is retrievable. Basic
Authentication stores the password using the one way
function. When the password comes across, the server uudecodes it and
then crypts it to check against the stored value. There is no way to
get the password from the crypted value. In MD5, you need the information
that is stored, so you can't use a one way hashing function to store it.
This means that MD5 requires more rigorous security on the server machine.
It is possible, but non-trivial, to implement this type of security under
the UnixTM security model.
So let's suppose you want to restrict files in a directory called
turkey to username
pumpkin and password
pie. Here's what to do:
Create a file called
.htaccess in directory
turkey that looks
AuthUserFile /otherdir/.htpasswd AuthGroupFile /dev/null AuthName ByPassword AuthType Basic <Limit GET> require user pumpkin </Limit>
Note that the password file will be in another directory
AuthUserFile must be the full Unix pathname of the password file.
Also note that in this case there is no group file, so we specify
/dev/null (the standard Unix way to say "this file
AuthName can be anything you want. The AuthName field
gives the Realm name for which the protection is provided. This name
is usually given when a browser prompts for a password, and is also usually
used by a browser in correlation with the URL to save the password information
you enter so that it can authenticate automatically on the next challenge.
Note: You should set this to something, otherwise it will default to
ByPassword, which is both non-descriptive and too common.
AuthType should be set to
Basic, since we are
using Basic HTTP Authentication. Other possibilities for NCSA HTTPd 1.5
are PEM, PGP, KerberosV4, KerberosV5, or Digest. These other types of
authentication will be discussed later.
In this example, only the method GET is restricted using the
directive. To limit other methods (particularly in CGI directories),
you can specify them separated by spaces in the
<LIMIT GET POST PUT> require user pumpkin </LIMIT>If you only use
GETprotection for a CGI script, you may be finding that the
REMOTE_USERenvironment variable is not getting set when using
METHOD="POST", obviously because the directory isn't protected against
Create the password file
The easiest way to do this is to use the
distributed with NCSA HTTPd. Do this:
htpasswd -c /otherdir/.htpasswd pumpkin
Type the password --
pie -- twice as instructed.
Check the resulting file to get a warm feeling of self-satisfaction; it should look like this:
That's all. Now try to access a file in directory
-- your browser should demand a username and password, and not give you
access to the file if you don't enter
pie. If you are using a browser that doesn't handle
authentication, you will not be able to access the document at all.
Add additional users to the directory's
htpasswd command without the
to add additional users; e.g.:
htpasswd /otherdir/.htpasswd peanuts htpasswd /otherdir/.htpasswd almonds htpasswd /otherdir/.htpasswd walnuts
Create a group file.
/otherdir/.htgroup and have it look something
my-users: pumpkin peanuts almonds walnuts
walnuts are the usernames.
Then modify the
file in the directory to look like this:
AuthUserFile /otherdir/.htpasswd AuthGroupFile /otherdir/.htgroup AuthName ByPassword AuthType Basic <Limit GET> require group my-users </Limit>
AuthGroupFile now points to your group file and
my-users (rather than individual user
pumpkin) is now required for access.
That's it. Now any user in group
my-users can use
his/her individual username and password to gain access to directory
Important Note: There is no correspondence between
usernames and passwords on specific Unix systems (e.g. in an
/etc/passwd file) and usernames and passwords in the
authentication schemes we're discussing for use in the Web. As
illustrated in the examples, Web-based authentication uses
similar but wholly distinct password files; a user need
never have an actual account on a given Unix system in order to
be validated for access to files being served from that system
and protected with HTTP-based authentication.
Note for non-NCSA readers: The
used in this case is as follows:
AuthUserFile /dev/null AuthGroupFile /dev/null AuthName ExampleAllowFromNCSA AuthType Basic <Limit GET> order deny,allow deny from all allow from .ncsa.uiuc.edu </Limit>
Note for NCSA readers: The
used in this case is as follows:
AuthUserFile /dev/null AuthGroupFile /dev/null AuthName ExampleDenyFromNCSA AuthType Basic <Limit GET> order allow,deny allow from all deny from .ncsa.uiuc.edu </Limit>