User Authentication Tutorial
Tutorial Contents
General Information
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 of .htaccess
How Secure Is It?
In Basic HTTP Authentication, the password is passed over the network not encrypted but not as plain text -- it is "uuencoded." Anyone watching packet traffic on the network will not see the password in the clear, but the password will be easily decoded by anyone who happens to catch the right network packet.
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.
Basic ByPassword Authentication: Step By Step
This should help you set up protection on a directory via the Basic HTTP Authentication method. This method also uses the standard plaintext password file.
So let's suppose you want to restrict files in a directory called test to username tester and password test123. Here's what to do:
Create a file
called .htaccess in directory test that looks like this:
AuthUserFile /test/.htpasswd
AuthGroupFile /dev/null
AuthName ByPassword
AuthType Basic
<Limit GET>
require user tester
</Limit>
Note that the password file will be in a directory (/test).
AuthUserFile must be the
full Unix pathname of the password file. OneNet user directories
are /onenet/users/orgname/Beginning_Letter_of_Username/Username/
For example, If your username is joe_smith and your organization is triton and you wish to protect the directory test, the AuthUserFile should be /onenet/users/triton/j/joe_smith/www/test/.htpasswd. Also note that in this
case there is no group file, so we specify /dev/null (the standard
Unix way to say "this file doesn't exist"). 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. In this example, only
the method GET is restricted using the LIMIT directive. To limit
other methods (particularly in CGI directories), you can specify them separated
by spaces in the LIMIT directive. For example: <LIMIT GET POST PUT> If you only use GET
protection for a CGI script, you may be finding that the REMOTE_USER
environment variable is not getting set when using METHOD="POST",
obviously because the directory isn't protected against POST. Create the password
file /test/.htpasswd The easiest way to do
this is to use the htpasswd
web page. This page was designed to assist you in creating
the .htpasswd file. It will require the user name and the
password to be entered twice for validation. The result will be displayed
for you to cut and paste into your .htpasswd file. tester:DCD3Pcrtc This
document is accessible only to user tester with password
test123. That's all. Now try to
access a file in directory accesstest -- your browser should demand
a username and password, and not give you access to the file if you don't
enter tester and test123. If you are using a browser that doesn't
handle authentication, you will not be able to access the document at all.
Multiple
Usernames/Passwords If you want to give access
to a directory to more than one username/password pair, follow the same steps
as for a single username/password with the following additions: Add additional users
to the directory's .htpasswd file. Use the htpasswd
web page to add the additional users below; e.g.: newtest Modify the .htpasswd
file by putting the new users' information. tester:DCD3Pcrtc AuthUserFile /test/.htpasswd That's it. Now any user
in the .htpasswd can use his/her individual username and password to gain
access to directory test1. Prepared
Examples Following are several
examples of the range of access authorization capabilities available. The
examples are served from a system at OneNet. Simple protection by
password. This
document is accessible only to user fido with password bones. 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. Protection by
password; multiple users allowed. This
document is accessible to user rover with password bacon
and user tom with password kitten. Protection by
network domain. This
document is only accessible to clients running on machines inside domain
onenet.net. Note for non-OneNet
readers: The .htaccess file used in this case is as follows:
AuthUserFile /dev/null Protection by
network domain -- exclusion. Note for OneNet readers:
The .htaccess file used in this case is as follows: AuthUserFile /dev/null Comments
or questions regarding OneNet: webmaster@onenet.net Copyright
2000-2001 by OneNet®
require user tester
</LIMIT>
anothertest
newtest:cHZiFPw7cXIMI
anothertest:KMfw0v5pT.voM
Then modify the .htaccess file in the directory to look like this:
AuthName ByPassword
AuthType Basic
<Limit GET>
require valid-user
</Limit>
Note that the require require line now just requires a valid-user (rather
than individual user tester) is now required for access.
AuthGroupFile /dev/null
AuthName ExampleAllowFromOneNet
AuthType Basic
<Limit GET>
order deny,allow
deny from all
allow from .onenet.net
</Limit>
AuthGroupFile /dev/null
AuthName ExampleDenyFromOneNet
AuthType Basic
<Limit GET>
order allow,deny
allow from all
deny from .onenet.net
</Limit>
