mirror of
https://github.com/apache/httpd.git
synced 2025-05-04 06:44:50 +03:00
91be236dd1
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95499 13f79535-47bb-0310-9956-ffa450edef68
380 lines
15 KiB
Plaintext
380 lines
15 KiB
Plaintext
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org" />
|
|
|
|
<title>Authentication</title>
|
|
<link rev="made" href="mailto:rbowen@rcbowen.com" />
|
|
</head>
|
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
|
|
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
|
|
vlink="#000080" alink="#FF0000">
|
|
<!--#include virtual="header.html" -->
|
|
|
|
<h1 align="center">Authentication</h1>
|
|
<a id="__index__" name="__index__"></a> <!-- INDEX BEGIN -->
|
|
|
|
|
|
<ul>
|
|
<li><a href="#introduction">Introduction</a></li>
|
|
|
|
<li><a href="#theprerequisites">The prerequisites</a></li>
|
|
|
|
<li><a href="#gettingitworking">Getting it working</a></li>
|
|
|
|
<li><a href="#lettingmorethanonepersonin">Letting more
|
|
than one person in</a></li>
|
|
|
|
<li><a href="#possibleproblems">Possible problems</a></li>
|
|
|
|
<li><a href="#whatotherneatstuffcanido">What other neat
|
|
stuff can I do?</a></li>
|
|
|
|
<li><a href="#moreinformation">More information</a></li>
|
|
</ul>
|
|
<!-- INDEX END -->
|
|
<hr />
|
|
|
|
<table border="1">
|
|
<tr>
|
|
<td valign="top"><strong>Related Modules</strong><br />
|
|
<br />
|
|
<a href="../mod/mod_auth.html">mod_auth</a><br />
|
|
<a href="../mod/mod_access.html">mod_access</a><br />
|
|
</td>
|
|
|
|
<td valign="top"><strong>Related Directives</strong><br />
|
|
<br />
|
|
<a href="../mod/mod_access.html#allow">Allow</a><br />
|
|
<a
|
|
href="../mod/mod_auth.html#authgroupfile">AuthGroupFile</a><br />
|
|
<a href="../mod/core.html#authname">AuthName</a><br />
|
|
<a href="../mod/core.html#authtype">AuthType</a><br />
|
|
<a
|
|
href="../mod/mod_auth.html#authuserfile">AuthUserFile</a><br />
|
|
<a href="../mod/mod_access.html#deny">Deny</a><br />
|
|
<a href="../mod/core.html#options">Options</a><br />
|
|
<a href="../mod/core.html#require">Require</a><br />
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h1><a id="authentication"
|
|
name="authentication">Authentication</a></h1>
|
|
|
|
<p>Authentication is any process by which you verify that
|
|
someone is who they claim they are. Authorization is any
|
|
process by which someone is allowed to be where they want to
|
|
go, or to have information that they want to have.</p>
|
|
|
|
<h2><a id="introduction"
|
|
name="introduction">Introduction</a></h2>
|
|
|
|
<p>If you have information on your web site that is sensitive
|
|
or intended for only a small group of people, the techniques in
|
|
this article will help you make sure that the people that see
|
|
those pages are the people that you wanted to see them.</p>
|
|
|
|
<p>This article covers the "standard" way of protecting parts
|
|
of your web site that most of you are going to use.</p>
|
|
|
|
<h2><a id="theprerequisites" name="theprerequisites">The
|
|
prerequisites</a></h2>
|
|
|
|
<p>The directives discussed in this article will need to go
|
|
either in your main server configuration file (typically in a
|
|
<Directory> section), or in per-directory configuration
|
|
files (<code>.htaccess</code> files).</p>
|
|
|
|
<p>If you plan to use <code>.htaccess</code> files, you will
|
|
need to have a server configuration that permits putting
|
|
authentication directives in these files. This is done with the
|
|
<code><a
|
|
href="../mod/core.html#allowoverride">AllowOverride</a></code>
|
|
directive, which specifies which directives, if any, may be put
|
|
in per-directory configuration files.</p>
|
|
|
|
<p>Since we're talking here about authentication, you will need
|
|
an <code>AllowOverride</code> directive like the following:</p>
|
|
<pre>
|
|
AllowOverride AuthConfig
|
|
</pre>
|
|
|
|
<p>Or, if you are just going to put the directives directly in
|
|
your main server configuration file, you will of course need to
|
|
have write permission to that file.</p>
|
|
|
|
<p>And you'll need to know a little bit about the directory
|
|
structure of your server, in order to know where some files are
|
|
kept. This should not be terribly difficult, and I'll try to
|
|
make this clear when we come to that point.</p>
|
|
|
|
<h2><a id="gettingitworking"
|
|
name="gettingitworking">Getting it working</a></h2>
|
|
|
|
<p>Here's the basics of password protecting a directory on your
|
|
server.</p>
|
|
|
|
<p>You'll need to create a password file. This file should be
|
|
placed somewhere not accessible from the web. This is so that
|
|
folks cannot download the password file. For example, if your
|
|
documents are served out of
|
|
<code>/usr/local/apache/htdocs</code> you might want to put the
|
|
password file(s) in <code>/usr/local/apache/passwd</code>.</p>
|
|
|
|
<p>To create the file, use the <a
|
|
href="../programs/htpasswd.html">htpasswd</a> utility that came
|
|
with Apache. This be located in the <code>bin</code> directory
|
|
of wherever you installed Apache. To create the file, type:</p>
|
|
<pre>
|
|
htpasswd -c /usr/local/apache/passwd/password rbowen
|
|
</pre>
|
|
|
|
<p><code>htpasswd</code> will ask you for the password, and
|
|
then ask you to type it again to confirm it:</p>
|
|
<pre>
|
|
# htpasswd -c /usr/local/apache/passwd/passwords rbowen
|
|
New password: mypassword
|
|
Re-type new password: mypassword
|
|
Adding password for user rbowen
|
|
</pre>
|
|
|
|
<p>If <code>htpasswd</code> is not in your path, of course
|
|
you'll have to type the full path to the file to get it to run.
|
|
On my server, it's located at
|
|
<code>/usr/local/apache/bin/htpasswd</code></p>
|
|
|
|
<p>Next, you'll need to configure the server to request a
|
|
password and tell the server which users are allowed access.
|
|
You can do this either by editing the <code>httpd.conf</code>
|
|
file or using an <code>.htaccess</code> file. For example, if
|
|
you wish to protect the directory
|
|
<code>/usr/local/apache/htdocs/secret</code>, you can use the
|
|
following directives, either placed in the file
|
|
<code>/usr/local/apache/htdocs/secret/.htaccess</code>, or
|
|
placed in httpd.conf inside a <Directory
|
|
/usr/local/apache/apache/htdocs/secret> section.</p>
|
|
<pre>
|
|
AuthType Basic
|
|
AuthName "Restricted Files"
|
|
AuthUserFile /usr/local/apache/passwd/passwords
|
|
require user rbowen
|
|
</pre>
|
|
|
|
<p>Let's examine each of those directives individually. The <a
|
|
href="../mod/core.html#authtype">AuthType</a> directive selects
|
|
that method that is used to authenticate the user. The most
|
|
common method is <code>Basic</code>, and this is the method
|
|
implemented by <a href="../mod/mod_auth.html">mod_auth</a>. It
|
|
is important to be aware, however, that Basic authentication
|
|
sends the password from the client to the browser unencrypted.
|
|
This method should therefore not be used for highly sensitive
|
|
data. Apache supports one other authentication method:
|
|
<code>AuthType Digest</code>. This method is implemented by <a
|
|
href="../mod/mod_auth_digest.html">mod_auth_digest</a> and is
|
|
much more secure. Only the most recent versions of clients are
|
|
known to support Digest authentication.</p>
|
|
|
|
<p>The <a href="../mod/core.html#authname">AuthName</a>
|
|
directive sets the <em>Realm</em> to be used in the
|
|
authentication. The realm serves two major functions. First,
|
|
the client often presents this information to the user as part
|
|
of the password dialog box. Second, it is used by the client to
|
|
determine what password to send for a given authenticated area.
|
|
So, for example, once a client has authenticated in the
|
|
<code>"Restricted Files"</code> area, it will automatically
|
|
retry the same password for any area on the same server that is
|
|
marked with the <code>"Restricted Files"</code> Realm.
|
|
Therefore, you can prevent a user from being prompted more than
|
|
once for a password by letting multiple restricted areas share
|
|
the same realm. Of course, for security reasons, the client
|
|
will always need to ask again for the password whenever the
|
|
hostname of the server changes.</p>
|
|
|
|
<p>The <a
|
|
href="../mod/mod_auth.html#authuserfile">AuthUserFile</a>
|
|
directive sets the path to the password file that we just
|
|
created with <code>htpasswd</code>. If you have a large number
|
|
of users, it can be quite slow to search through a plain text
|
|
file to authenticate the user on each request. Apache also has
|
|
the ability to store user information in fast database files.
|
|
The <a href="../mod/mod_auth_dbm.html">mod_auth_dbm</a> module
|
|
provides the <a
|
|
href="../mod/mod_auth_dbm.html#authdbmuserfile">AuthDBMUserFile</a>
|
|
directive. These files can be created and
|
|
manipulated with the <a
|
|
href="../programs/dbmmanage.html">dbmmanage</a> program. Many
|
|
other types of authentication options are available from third
|
|
party modules in the <a
|
|
href="http://modules.apache.org/">Apache Modules
|
|
Database</a>.</p>
|
|
|
|
<p>Finally, the <a href="../mod/core.html#require">require</a>
|
|
directive provides the authorization part of the process by
|
|
setting the user that is allowed to access this region of the
|
|
server. In the next section, we discuss various ways to use the
|
|
<code>require</code> directive.</p>
|
|
|
|
<h2><a id="lettingmorethanonepersonin"
|
|
name="lettingmorethanonepersonin">Letting more than one
|
|
person in</a></h2>
|
|
|
|
<p>The directives above only let one person (specifically
|
|
someone with a username of <code>rbowen</code>) into the
|
|
directory. In most cases, you'll want to let more than one
|
|
person in. This is where the <a
|
|
href="../mod/mod_auth.html#authgroupfile">AuthGroupFile</a>
|
|
comes in.</p>
|
|
|
|
<p>If you want to let more than one person in, you'll need to
|
|
create a group file that associates group names with a list of
|
|
users in that group. The format of this file is pretty simple,
|
|
and you can create it with your favorite editor. The contents
|
|
of the file will look like this:</p>
|
|
<pre>
|
|
GroupName: rbowen dpitts sungo rshersey
|
|
</pre>
|
|
|
|
<p>That's just a list of the members of the group in a long
|
|
line separated by spaces.</p>
|
|
|
|
<p>To add a user to your already existing password file,
|
|
type:</p>
|
|
<pre>
|
|
htpasswd /usr/local/apache/passwd/password dpitts
|
|
</pre>
|
|
|
|
<p>You'll get the same response as before, but it will be
|
|
appended to the existing file, rather than creating a new file.
|
|
(It's the <code>-c</code> that makes it create a new password
|
|
file).</p>
|
|
|
|
<p>Now, you need to modify your <code>.htaccess</code> file to
|
|
look like the following:</p>
|
|
<pre>
|
|
AuthType Basic
|
|
AuthName "By Invitation Only"
|
|
AuthUserFile /usr/local/apache/passwd/passwords
|
|
AuthGroupFile /usr/local/apache/passwd/groups
|
|
require group GroupName
|
|
</pre>
|
|
|
|
<p>Now, anyone that is listed in the group
|
|
<code>GroupName</code>, and has an entry in the
|
|
<code>password</code> file, will be let in, if they type the
|
|
correct password.</p>
|
|
|
|
<p>There's another way to let multiple users in that is less
|
|
specific. Rather than creating a group file, you can just use
|
|
the following directive:</p>
|
|
<pre>
|
|
require valid-user
|
|
</pre>
|
|
|
|
<p>Using that rather than the <code>require user rbowen</code>
|
|
line will allow anyone in that is listed in the password file,
|
|
and who correctly enters their password. You can even emulate
|
|
the group behavior here, by just keeping a separate password
|
|
file for each group. The advantage of this approach is that
|
|
Apache only has to check one file, rather than two. The
|
|
disadvantage is that you have to maintain a bunch of password
|
|
files, and remember to reference th right one in the
|
|
<code>AuthUserFile</code> directive.</p>
|
|
|
|
<h2><a id="possibleproblems" name="possibleproblems">Possible
|
|
problems</a></h2>
|
|
|
|
<p>Because of the way that Basic authentication is specified,
|
|
your username and password must be verified every time you
|
|
request a document from the server. This is even if you're
|
|
reloading the same page, and for every image on the page (if
|
|
they come from a protected directory). As you can imagine, this
|
|
slows things down a little. The amount that it slows things
|
|
down is proportional to the size of the password file, because
|
|
it has to open up that file, and go down the list of users
|
|
until it gets to your name. And it has to do this every time a
|
|
page is loaded.</p>
|
|
|
|
<p>A consequence of this is that there's a practical limit to
|
|
how many users you can put in one password file. This limit
|
|
will vary depending on the performance of your particular
|
|
server machine, but you can expect to see slowdowns once you
|
|
get above a few hundred entries, and may wish to consider a
|
|
different authentication method at that time.</p>
|
|
|
|
<h2><a id="whatotherneatstuffcanido"
|
|
name="whatotherneatstuffcanido">What other neat stuff can
|
|
I do?</a></h2>
|
|
|
|
<p>Authentication by username and password is only part of the
|
|
story. Frequently you want to let people in based on something
|
|
other than who they are. Something such as where they are
|
|
coming from.</p>
|
|
|
|
<p>The <code>allow</code> and <code>deny</code> directives let
|
|
you allow and deny access based on the host name, or host
|
|
address, of the machine requesting a document. The
|
|
<code>order</code> directive goes hand-in-hand with these two,
|
|
and tells Apache in which order to apply the filters.</p>
|
|
|
|
<p>The usage of these directives is:</p>
|
|
<pre>
|
|
allow from address
|
|
</pre>
|
|
|
|
<p>where <em>address</em> is an IP address (or a partial IP
|
|
address) or a fully qualified domain name (or a partial domain
|
|
name); you may provide multiple addresses or domain names, if
|
|
desired.</p>
|
|
|
|
<p>For example, if you have someone spamming your message
|
|
board, and you want to keep them out, you could do the
|
|
following:</p>
|
|
<pre>
|
|
deny from 205.252.46.165
|
|
</pre>
|
|
|
|
<p>Visitors coming from that address will not be able to see
|
|
the content covered by this directive. If, instead, you have a
|
|
machine name, rather than an IP address, you can use that.</p>
|
|
<pre>
|
|
deny from host.example.com
|
|
</pre>
|
|
|
|
<p>And, if you'd like to block access from an entire domain,
|
|
you can specify just part of an address or domain name:</p>
|
|
<pre>
|
|
deny from 192.101.205
|
|
deny from cyberthugs.com moreidiots.com
|
|
deny from ke
|
|
</pre>
|
|
|
|
<p>Using <code>order</code> will let you be sure that you are
|
|
actually restricting things to the group that you want to let
|
|
in, by combining a <code>deny</code> and an <code>allow</code>
|
|
directive:</p>
|
|
<pre>
|
|
order deny,allow
|
|
deny from all
|
|
allow from dev.example.com
|
|
</pre>
|
|
|
|
<p>Listing just the <code>allow</code> directive would not do
|
|
what you want, because it will let folks from that host in, in
|
|
addition to letting everyone in. What you want is to let
|
|
<em>only</em> those folks in.</p>
|
|
|
|
<h2><a id="moreinformation" name="moreinformation">More
|
|
information</a></h2>
|
|
|
|
<p>You should also read the documentation for <code><a
|
|
href="../mod/mod_auth.html">mod_auth</a></code> and <code><a
|
|
href="../mod/mod_access.html">mod_access</a></code> which
|
|
contain some more information about how this all works.</p>
|
|
</body>
|
|
</html>
|
|
|