mirror of
https://github.com/apache/httpd.git
synced 2025-05-02 20:04:52 +03:00
37af7a852e
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@567134 13f79535-47bb-0310-9956-ffa450edef68
642 lines
36 KiB
XML
642 lines
36 KiB
XML
<?xml version="1.0" encoding="ISO-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!--
|
|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
This file is generated from xml source: DO NOT EDIT
|
|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
-->
|
|
<title>Authentication, Authorization and Access Control - Apache HTTP Server</title>
|
|
<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
|
|
<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
|
|
<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
|
|
<link href="../images/favicon.ico" rel="shortcut icon" /></head>
|
|
<body id="manual-page"><div id="page-header">
|
|
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p>
|
|
<p class="apache">Apache HTTP Server Version 2.3</p>
|
|
<img alt="" src="../images/feather.gif" /></div>
|
|
<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
|
|
<div id="path">
|
|
<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.3</a> > <a href="./">How-To / Tutorials</a></div><div id="page-content"><div id="preamble"><h1>Authentication, Authorization and Access Control</h1>
|
|
<div class="toplang">
|
|
<p><span>Available Languages: </span><a href="../en/howto/auth.html" title="English"> en </a> |
|
|
<a href="../ja/howto/auth.html" hreflang="ja" rel="alternate" title=""> ja </a> |
|
|
<a href="../ko/howto/auth.html" hreflang="ko" rel="alternate" title=""> ko </a></p>
|
|
</div>
|
|
|
|
<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>
|
|
</div>
|
|
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#related">Related Modules and Directives</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#introduction">Introduction</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#theprerequisites">The Prerequisites</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#gettingitworking">Getting it working</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#lettingmorethanonepersonin">Letting more than one
|
|
person in</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#possibleproblems">Possible problems</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#dbmdbd">Alternate password storage</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#multprovider">Using multiple providers</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#beyond">Beyond just authorization</a></li>
|
|
<li><img alt="" src="../images/down.gif" /> <a href="#moreinformation">More information</a></li>
|
|
</ul></div>
|
|
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="related" id="related">Related Modules and Directives</a></h2>
|
|
|
|
<p>There are three types of modules involved in the authentication and
|
|
authorization process. You will usually need to choose at least one
|
|
module from each group.</p>
|
|
|
|
<ul>
|
|
<li>Authentication type (see the
|
|
<code class="directive"><a href="../mod/core.html#authtype">AuthType</a></code> directive)
|
|
<ul>
|
|
<li><code class="module"><a href="../mod/mod_auth_basic.html">mod_auth_basic</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_auth_digest.html">mod_auth_digest</a></code></li>
|
|
</ul>
|
|
</li>
|
|
<li>Authentication provider (see the
|
|
<code class="directive"><a href="../mod/mod_auth_basic.html#authbasicprovider">AuthBasicProvider</a></code> and
|
|
<code class="directive"><a href="../mod/mod_auth_digest.html#authdigestprovider">AuthDigestProvider</a></code> directives)
|
|
|
|
<ul>
|
|
<li><code class="module"><a href="../mod/mod_authn_anon.html">mod_authn_anon</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authn_dbd.html">mod_authn_dbd</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authn_dbm.html">mod_authn_dbm</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authn_default.html">mod_authn_default</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authn_file.html">mod_authn_file</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authnz_ldap.html">mod_authnz_ldap</a></code></li>
|
|
</ul>
|
|
</li>
|
|
<li>Authorization (see the
|
|
<code class="directive"><a href="../mod/core.html#require">Require</a></code> directive)
|
|
<ul>
|
|
<li><code class="module"><a href="../mod/mod_authnz_ldap.html">mod_authnz_ldap</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authz_dbm.html">mod_authz_dbm</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authz_dbm.html">mod_authz_dbm</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authz_default.html">mod_authz_default</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authz_groupfile.html">mod_authz_groupfile</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authz_host.html">mod_authz_host</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authz_owner.html">mod_authz_owner</a></code></li>
|
|
<li><code class="module"><a href="../mod/mod_authz_user.html">mod_authz_user</a></code></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>In addition to these modules, there are also
|
|
<code class="module"><a href="../mod/mod_authn_core.html">mod_authn_core</a></code> and
|
|
<code class="module"><a href="../mod/mod_authz_core.html">mod_authz_core</a></code>. These module implement core
|
|
directives that are core to all auth modules.</p>
|
|
|
|
<p>The module <code class="module"><a href="../mod/mod_authnz_ldap.html">mod_authnz_ldap</a></code> is both an
|
|
authentication and authorization provider. The module
|
|
<code class="module"><a href="../mod/mod_authz_host.html">mod_authz_host</a></code> provides authorization
|
|
and access control based on hostname, IP address or characteristics
|
|
of the request, but is not part of the authentication provider
|
|
system. For backwards compatibility with the mod_access, there is
|
|
a new module <code class="module"><a href="../mod/mod_access_compat.html">mod_access_compat</a></code>.</p>
|
|
|
|
<p>You probably also want to take a look at the <a href="access.html">Access Control</a> howto, which discusses the
|
|
various ways to control access to your server.</p>
|
|
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="introduction" id="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>
|
|
|
|
<div class="note"><h3>Note:</h3>
|
|
<p>If your data really needs to be secure, consider using
|
|
<code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> in addition to any authentication.</p>
|
|
</div>
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="theprerequisites" id="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
|
|
<code class="directive"><a href="../mod/core.html#directory"><Directory></a></code> 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 class="directive"><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 class="directive"><a href="../mod/core.html#allowoverride">AllowOverride</a></code> directive like the
|
|
following:</p>
|
|
|
|
<div class="example"><p><code>
|
|
AllowOverride AuthConfig
|
|
</code></p></div>
|
|
|
|
<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>
|
|
|
|
<p>You will also need to make sure that the modules
|
|
<code class="module"><a href="../mod/mod_authn_core.html">mod_authn_core</a></code> and <code class="module"><a href="../mod/mod_authz_core.html">mod_authz_core</a></code>
|
|
have either been built into the httpd binary or loaded by the
|
|
httpd.conf configuration file. Both of these modules provide core
|
|
directives and functionality that are critical to the configuration
|
|
and use of authentication and authorization in the web server.</p>
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="gettingitworking" id="gettingitworking">Getting it working</a></h2>
|
|
<p>Here's the basics of password protecting a directory on your
|
|
server.</p>
|
|
|
|
<p>First, you need to create a password file. Exactly how you do
|
|
this will vary depending on what authentication provider you have
|
|
chosen. More on that later. To start with, we'll use a text password
|
|
file.</p>
|
|
|
|
<p>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 <code class="program"><a href="../programs/htpasswd.html">htpasswd</a></code> utility that
|
|
came with Apache. This will be located in the <code>bin</code> directory
|
|
of wherever you installed Apache. If you have installed Apache from
|
|
a third-party package, it may be in your execution path.</p>
|
|
|
|
<p>To create the file, type:</p>
|
|
|
|
<div class="example"><p><code>
|
|
htpasswd -c /usr/local/apache/passwd/passwords rbowen
|
|
</code></p></div>
|
|
|
|
<p><code class="program"><a href="../programs/htpasswd.html">htpasswd</a></code> will ask you for the password, and
|
|
then ask you to type it again to confirm it:</p>
|
|
|
|
<div class="example"><p><code>
|
|
# htpasswd -c /usr/local/apache/passwd/passwords rbowen<br />
|
|
New password: mypassword<br />
|
|
Re-type new password: mypassword<br />
|
|
Adding password for user rbowen
|
|
</code></p></div>
|
|
|
|
<p>If <code class="program"><a href="../programs/htpasswd.html">htpasswd</a></code> is not in your path, of course
|
|
you'll have to type the full path to the file to get it to run.
|
|
With a default installation, it's located at
|
|
<code>/usr/local/apache2/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 <code>httpd.conf</code> inside a <Directory
|
|
/usr/local/apache/htdocs/secret> section.</p>
|
|
|
|
<div class="example"><p><code>
|
|
AuthType Basic<br />
|
|
AuthName "Restricted Files"<br />
|
|
# (Following line optional)<br />
|
|
AuthBasicProvider file<br />
|
|
AuthUserFile /usr/local/apache/passwd/passwords<br />
|
|
Require user rbowen
|
|
</code></p></div>
|
|
|
|
<p>Let's examine each of those directives individually. The <code class="directive"><a href="../mod/core.html#authtype">AuthType</a></code> 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 <code class="module"><a href="../mod/mod_auth_basic.html">mod_auth_basic</a></code>. It is important to be aware,
|
|
however, that Basic authentication sends the password from the client to
|
|
the server unencrypted. This method should therefore not be used for
|
|
highly sensitive data, unless accompanied by <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code>.
|
|
Apache supports one other authentication method:
|
|
<code>AuthType Digest</code>. This method is implemented by <code class="module"><a href="../mod/mod_auth_digest.html">mod_auth_digest</a></code> and is much more secure. Most recent
|
|
browsers support Digest authentication.</p>
|
|
|
|
<p>The <code class="directive"><a href="../mod/core.html#authname">AuthName</a></code> directive sets
|
|
the <dfn>Realm</dfn> 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.</p>
|
|
|
|
<p>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 <code class="directive"><a href="../mod/mod_auth_basic.html#authbasicprovider">AuthBasicProvider</a></code> is,
|
|
in this case, optional, since <code>file</code> is the default value
|
|
for this directive. You'll need to use this directive if you are
|
|
choosing a different source for authentication, such as
|
|
<code class="module"><a href="../mod/mod_authn_dbm.html">mod_authn_dbm</a></code> or <code class="module"><a href="../mod/mod_authn_dbd.html">mod_authn_dbd</a></code>.</p>
|
|
|
|
<p>The <code class="directive"><a href="../mod/mod_authn_file.html#authuserfile">AuthUserFile</a></code>
|
|
directive sets the path to the password file that we just
|
|
created with <code class="program"><a href="../programs/htpasswd.html">htpasswd</a></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 <code class="module"><a href="../mod/mod_authn_dbm.html">mod_authn_dbm</a></code> module provides the <code class="directive"><a href="../mod/mod_authn_dbm.html#authdbmuserfile">AuthDBMUserFile</a></code> directive. These
|
|
files can be created and manipulated with the <code class="program"><a href="../programs/dbmmanage.html">dbmmanage</a></code> 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 <code class="directive"><a href="../mod/core.html#require">Require</a></code>
|
|
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 class="directive"><a href="../mod/core.html#require">Require</a></code> directive.</p>
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="lettingmorethanonepersonin" id="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 <code class="directive"><a href="../mod/mod_authz_groupfile.html#authgroupfile">AuthGroupFile</a></code> 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>
|
|
|
|
<div class="example"><p><code>
|
|
GroupName: rbowen dpitts sungo rshersey
|
|
</code></p></div>
|
|
|
|
<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>
|
|
|
|
<div class="example"><p><code>
|
|
htpasswd /usr/local/apache/passwd/passwords dpitts
|
|
</code></p></div>
|
|
|
|
<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>
|
|
|
|
<div class="example"><p><code>
|
|
AuthType Basic<br />
|
|
AuthName "By Invitation Only"<br />
|
|
# Optional line:<br />
|
|
AuthBasicProvider file<br />
|
|
AuthUserFile /usr/local/apache/passwd/passwords<br />
|
|
AuthGroupFile /usr/local/apache/passwd/groups<br />
|
|
Require group GroupName
|
|
</code></p></div>
|
|
|
|
<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>
|
|
|
|
<div class="example"><p><code>
|
|
Require valid-user
|
|
</code></p></div>
|
|
|
|
<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 the right one in the
|
|
<code class="directive"><a href="../mod/mod_authn_file.html#authuserfile">AuthUserFile</a></code> directive.</p>
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="possibleproblems" id="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>
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="dbmdbd" id="dbmdbd">Alternate password storage</a></h2>
|
|
|
|
<p>Because storing passwords in plain text files has the above
|
|
problems, you may wish to store your passwords somewhere else, such
|
|
as in a database.</p>
|
|
|
|
<p><code class="module"><a href="../mod/mod_authn_dbm.html">mod_authn_dbm</a></code> and <code class="module"><a href="../mod/mod_authn_dbd.html">mod_authn_dbd</a></code>
|
|
are two modules which make this possible. Rather than selecting
|
|
<code class="directive"><a href="../mod/mod_auth_basic.html#authbasicsource">AuthBasicSource</a></code> file,
|
|
instead you can choose <code>dbm</code> or <code>dbd</code> as your
|
|
storage format.</p>
|
|
|
|
<p>To select a dbd file rather than a text file, for example:</p>
|
|
|
|
<div class="example"><p><code>
|
|
<Directory /www/docs/private><br />
|
|
AuthName "Private"<br />
|
|
AuthType Basic<br />
|
|
AuthBasicProvider dbm<br />
|
|
AuthDBMUserFile /www/passwords/passwd.dbm<br />
|
|
Require valid-user<br />
|
|
</Directory>
|
|
</code></p></div>
|
|
|
|
<p>Other options are available. Consult the
|
|
<code class="module"><a href="../mod/mod_authn_dbm.html">mod_authn_dbm</a></code> documentation for more details.</p>
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="multprovider" id="multprovider">Using multiple providers</a></h2>
|
|
|
|
<p>With the introduction of the new provider based authentication and
|
|
authorization architecture, you are no longer locked into a single
|
|
authentication or authorization method. In fact any number of the
|
|
providers can be mixed and matched to provide you with exactly the
|
|
scheme that meets your needs. In the following example, both the
|
|
file and ldap based authentication providers are being used.</p>
|
|
|
|
<div class="example"><p><code>
|
|
<Directory /www/docs/private><br />
|
|
AuthName "Private"<br />
|
|
AuthType Basic<br />
|
|
AuthBasicProvider file ldap<br />
|
|
AuthUserFile /usr/local/apache/passwd/passwords<br />
|
|
AuthLDAPURL ldap://ldaphost/o=yourorg<br />
|
|
Require valid-user
|
|
</Directory>
|
|
</code></p></div>
|
|
|
|
<p>In this example the file provider will attempt to authenticate
|
|
the user first. If it is unable to authenticate the user, the ldap
|
|
provider will be called. This allows the scope of authentication
|
|
to be broadened if your organization implements more than
|
|
one type of authentication store. Other authentication and authorization
|
|
scenarios may include mixing one type of authentication with a
|
|
different type of authorization. For example, authenticating against
|
|
a password file yet authorizing against and ldap directory.</p>
|
|
|
|
<p>Just as multiple authentication providers can be implemented, multiple
|
|
authorization methods can also be used. In this example both file group
|
|
authorization as well as ldap group authorization is being used.</p>
|
|
|
|
<div class="example"><p><code>
|
|
<Directory /www/docs/private><br />
|
|
AuthName "Private"<br />
|
|
AuthType Basic<br />
|
|
AuthBasicProvider file<br />
|
|
AuthUserFile /usr/local/apache/passwd/passwords<br />
|
|
AuthLDAPURL ldap://ldaphost/o=yourorg
|
|
AuthGroupFile /usr/local/apache/passwd/groups<br />
|
|
Require group GroupName<br />
|
|
Require ldap-group cn=mygroup,o=yourorg
|
|
</Directory>
|
|
</code></p></div>
|
|
|
|
<p>To take authorization a little further, the directives
|
|
<code class="directive"><a href="../mod/mod_authz_core.html#<satisfyall>"><SatisfyAll></a></code> and
|
|
<code class="directive"><a href="../mod/mod_authz_core.html#<satisfyone>"><SatisfyOne></a></code> allow
|
|
AND/OR logic to be applied so that the order in which authorization
|
|
is handled can be completely controled through the configuration. See
|
|
these directives for a complete example on they can be applied.</p>
|
|
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="beyond" id="beyond">Beyond just authorization</a></h2>
|
|
|
|
<p>The way that authorization can be apply is now much more flexible
|
|
than just a single check against a single data store. Ordering, logic
|
|
and choosing how authorization will be done is now possible.</p>
|
|
|
|
<h3><a name="authandororder" id="authandororder">Applying AND/OR logic and ordering</a></h3>
|
|
<p>Controling how and in what order authorization will be applied
|
|
has been a bit of a mystery in the past. In Apache 2.2 a provider based
|
|
authentication mechanism was introduced to decouple the actual
|
|
authentication process from authorization and supporting functionality.
|
|
One of the side benefits was that authentication providers could be
|
|
configured and called in a specific order which didn't depend on the
|
|
load order of the auth module itself. This same provider based mechanism
|
|
has been brought forward into authorization as well. What this means is
|
|
that the <code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code> directive
|
|
not only specifies which authorization methods should be used, it also
|
|
specifies the order in which they are called. Multiple authorization
|
|
methods are called in the same order in which the
|
|
<code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code> directives appear
|
|
in the configuration.</p>
|
|
|
|
<p>With the introduction of the directives
|
|
<code class="directive"><a href="../mod/mod_authz_core.html#<satisfyall>"><SatisfyAll></a></code> and
|
|
<code class="directive"><a href="../mod/mod_authz_core.html#<satisfyone>"><SatisfyOne></a></code>, the
|
|
configuration also has control over when the
|
|
authorization methods are called and what criteria determines when
|
|
access is granted. For example the following authorization block would
|
|
apply the logic:</p>
|
|
|
|
<div class="example"><p><code>
|
|
# if ((user == "John") ||<br />
|
|
# ((Group == "admin")<br />
|
|
# && (ldap-group <ldap-object> contains auth'ed_user)<br />
|
|
# && ((ldap-attribute dept == "sales")<br />
|
|
# || (file-group contains auth'ed_user))))<br />
|
|
# then<br />
|
|
# auth_granted<br />
|
|
# else<br />
|
|
# auth_denied<br />
|
|
#<br />
|
|
<Directory /www/mydocs><br />
|
|
<span class="indent">
|
|
Authname ...<br />
|
|
AuthBasicProvider ...<br />
|
|
...<br />
|
|
Require user John<br />
|
|
<SatisfyAll><br />
|
|
<span class="indent">
|
|
Require Group admins<br />
|
|
Require ldap-group cn=mygroup,o=foo<br />
|
|
<SatisfyOne><br />
|
|
<span class="indent">
|
|
Require ldap-attribute dept="sales"<br />
|
|
Require file-group<br />
|
|
</span>
|
|
</SatisfyOne><br />
|
|
</span>
|
|
</SatisfyAll><br />
|
|
</span>
|
|
</Directory>
|
|
</code></p></div>
|
|
|
|
<p>By default all <code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code>
|
|
directives are handled through and OR operation. In other words, if
|
|
any of the specified authorization methods succeed, then authorization
|
|
is granted. By enclosing a set of
|
|
<code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code> directives within
|
|
a <code class="directive"><a href="../mod/mod_authz_core.html#<satisfyall>"><SatisfyAll></a></code> block,
|
|
the processing switches to an AND operation which requires all authorization
|
|
methods to succeed before authorization is granted.</p>
|
|
|
|
|
|
|
|
<h3><a name="reqaccessctrl" id="reqaccessctrl">Using 'Require' or 'Reject' for access control</a></h3>
|
|
<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 authorization providers <code class="directive"><a href="../mod/mod_authz_host.html# all">
|
|
all</a></code>, <code class="directive"><a href="../mod/mod_authz_host.html# env">
|
|
env</a></code>, <code class="directive"><a href="../mod/mod_authz_host.html# host">
|
|
host</a></code> and <code class="directive"><a href="../mod/mod_authz_host.html# ip">
|
|
ip</a></code> let you allow or deny access based other host based
|
|
criteria such as host name or ip address of the machine requesting
|
|
a document.</p>
|
|
|
|
<p>The usage of these providers is specified through the
|
|
<code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code> and
|
|
<code class="directive"><a href="../mod/mod_authz_core.html#reject">Reject</a></code> directives.
|
|
These directives register the authorization providers
|
|
that will be called during the authorization stage of the request
|
|
processing. For example:</p>
|
|
|
|
<div class="example"><p><code>
|
|
Require ip <var>address</var>
|
|
</code></p></div>
|
|
|
|
<p>where <var>address</var> is an IP address (or a partial IP
|
|
address) or:</p>
|
|
|
|
<div class="example"><p><code>
|
|
Require host <var>domain_name</var>
|
|
</code></p></div>
|
|
|
|
<p>where <var>domain_name</var> is 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>
|
|
|
|
<div class="example"><p><code>
|
|
Reject ip 10.252.46.165
|
|
</code></p></div>
|
|
|
|
<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>
|
|
|
|
<div class="example"><p><code>
|
|
Reject host <var>host.example.com</var>
|
|
</code></p></div>
|
|
|
|
<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>
|
|
|
|
<div class="example"><p><code>
|
|
<SatisfyAll><br />
|
|
<span class="indent">
|
|
Reject ip <var>192.168.205</var><br />
|
|
Reject host <var>phishers.example.com</var> <var>moreidiots.example</var><br /> Reject host ke<br />
|
|
</span>
|
|
</SatisfyAll>
|
|
</code></p></div>
|
|
|
|
<p>Using the <code class="directive"><a href="../mod/mod_authz_host.html#reject">Reject</a></code> directive
|
|
inside of a <code class="directive"><a href="../mod/mod_authz_core.html#<satisfyall>"><SatisfyAll></a></code>
|
|
block, will let you be sure that you are actually restricting things to
|
|
only the group that you want to let in.</p>
|
|
|
|
<p>The above example uses the <code class="directive"><a href="../mod/mod_authz_core.html# <satisfyall>">
|
|
<SatisfyAll></a></code> block to make sure that all of the
|
|
<code class="directive"><a href="../mod/mod_authz_host.html#reject">Reject</a></code> directives are
|
|
satisfied before granting access. </p>
|
|
|
|
|
|
|
|
<h3><a name="filesystem" id="filesystem">Access Control backwards compatibility</a></h3>
|
|
<p>One of the side effects of adopting a provider based mechanism for
|
|
authentication is that the need for the previous access control directives
|
|
<code class="directive"><a href="../mod/mod_access_compat.html#order">Order</a></code>,
|
|
<code class="directive"><a href="../mod/mod_access_compat.html#allow">Allow</a></code>,
|
|
<code class="directive"><a href="../mod/mod_access_compat.html#deny">Deny</a></code> and
|
|
<code class="directive"><a href="../mod/mod_access_compat.html#satisfy">Satisfy</a></code> are no longer needed.
|
|
However to provide backwards compatibility for older configurations, these
|
|
directives have been moved to the <code class="module"><a href="../mod/mod_access_compat.html">mod_access_compat</a></code> module.</p>
|
|
|
|
<p>One of the problems with these directives was that the line between
|
|
authorization and access control was very fuzzy. The
|
|
<code class="directive"><a href="../mod/mod_access_compat.html#satisfy">Satisfy</a></code> directive
|
|
tried to tie these two stages together by hooking itself into the
|
|
request processing itself. Now that these directive have been moved to the
|
|
<code class="module"><a href="../mod/mod_access_compat.html">mod_access_compat</a></code>, mixing the new authorization directives
|
|
with the older access control directives becomes difficult. To address this
|
|
issue, the <code class="module"><a href="../mod/mod_authz_default.html">mod_authz_default</a></code> module becomes very important and must
|
|
be loaded. The main purpose of the <code class="module"><a href="../mod/mod_authz_default.html">mod_authz_default</a></code> module is
|
|
to handle any authorization requests that could not be handled by the
|
|
authorization providers. But when the older access control directives are used,
|
|
it also links access control with authorization and determines if access
|
|
should be granted based on the outcome of each stage. Therefore if the
|
|
older directives do not seem to be working properly, it might be because the
|
|
<code class="module"><a href="../mod/mod_authz_default.html">mod_authz_default</a></code> module has not been loaded.</p>
|
|
|
|
|
|
|
|
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
|
|
<div class="section">
|
|
<h2><a name="moreinformation" id="moreinformation">More information</a></h2>
|
|
<p>You should also read the documentation for
|
|
<code class="module"><a href="../mod/mod_auth_basic.html">mod_auth_basic</a></code> and <code class="module"><a href="../mod/mod_authz_host.html">mod_authz_host</a></code> which
|
|
contain some more information about how this all works.
|
|
The directive <code class="directive"><a href="../mod/mod_authn_core.html#<authnprovideralias>"><AuthnProviderAlias></a></code>
|
|
can also help in simplifying certain authentication configurations.</p>
|
|
|
|
<p>And you may want to look at the <a href="access.html">Access
|
|
Control</a> howto, which discusses a number of related topics.</p>
|
|
|
|
</div></div>
|
|
<div class="bottomlang">
|
|
<p><span>Available Languages: </span><a href="../en/howto/auth.html" title="English"> en </a> |
|
|
<a href="../ja/howto/auth.html" hreflang="ja" rel="alternate" title=""> ja </a> |
|
|
<a href="../ko/howto/auth.html" hreflang="ko" rel="alternate" title=""> ko </a></p>
|
|
</div><div id="footer">
|
|
<p class="apache">Copyright 2006 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
|
|
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div>
|
|
</body></html> |