httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rbo...@apache.org
Subject cvs commit: httpd-docs-1.3/htdocs/manual/howto auth.html
Date Fri, 23 Nov 2001 05:01:21 GMT
rbowen      01/11/22 21:01:21

  Added:       htdocs/manual/howto auth.html
  Log:
  New authentication tutorial/howto
  
  Revision  Changes    Path
  1.1                  httpd-docs-1.3/htdocs/manual/howto/auth.html
  
  Index: auth.html
  ===================================================================
  <!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>
      <title>Authentication, Authorization, and Access Control</title>
    </head>
  
    <body>
      <!--Table of Child-Links-->
      <a name="TOC"><strong>Subsections</strong></a> 
  
      <ul>
        <li><a href="#intro">Introduction</a></li>
  
        <li>
          <a href="#basic">Basic authentication</a> 
  
          <ul>
            <li><a href="#basicworks">How basic
            authentication works</a></li>
  
            <li>
              <a href="#basicconfig">Configuration:
              Protecting content with basic authentication</a> 
  
              <ul>
                <li><a href="#htpasswd">Create a password
                file</a></li>
  
                <li><a href="#htpasswdconfig">Set the
                configuration to use this password file</a></li>
  
                <li><a href="#basicgroupfile">Optionally,
                create a group file</a></li>
              </ul>
            </li>
  
            <li>
              <a href="#basicfaq">Frequently asked
              questions about basic auth</a> 
  
              <ul>
                <li><a href="#logout">How do I log
                out?</a></li>
  
                <li><a href="#passworddialog">How can I change
                what the password box looks like?</a></li>
  
                <li><a href="#persistpass">How to I make it
                not ask me for my password the next time?</a></li>
  
                <li><a href="#passwordtwice">Why does it
                sometimes ask me for my password twice?</a></li>
              </ul>
            </li>
  
            <li><a href="#basiccaveat">Security
            caveat</a></li>
          </ul>
          <br />
        </li>
  
        <li>
          <a href="#digest">Digest authentication</a> 
  
          <ul>
            <li><a href="#digestworks">How digest auth
            works</a></li>
  
            <li>
              <a href="#digestconfig">Configuration:
              Protecting content with digest authentication</a> 
  
              <ul>
                <li><a href="#htdigest">Creating a
                password file</a></li>
  
                <li><a href="#htdigestconfig">Set the
                configuration to use this password file</a></li>
  
                <li><a href="#digestgroup">Optionally,
                create a group file</a></li>
              </ul>
            </li>
  
            <li><a href="#digestcaveat">Caveats</a></li>
          </ul>
          <br />
        </li>
  
        <li>
          <a href="#database">Database authentication
          modules</a> 
  
          <ul>
            <li><a href="#modauthdb">mod_auth_db and
            mod_auth_dbm</a></li>
  
            <li><a href="#dbfiles">Berkeley DB files</a></li>
  
            <li><a href="#installauthdb">Installing mod_auth_db</a></li>
  
            <li>
              <a href="#authdbconfig">Protecting a
              directory with mod_auth_db</a> 
  
              <ul>
                <li><a href="#dbmmanage">Create the user
                file</a></li>
  
                <li><a href="#perl_dbfile">Creating your
                user file with Perl</a></li>
  
                <li><a href="#authdbuserfile">Configuration
                Apache to use this password file</a></li>
  
                <li><a href="#authdbgroupfile">Optionally,
                create a group file</a></li>
              </ul>
            </li>
          </ul>
          <br />
        </li>
  
        <li>
          <a href="#access">Access control</a> 
  
          <ul>
            <li><a href="#allowdeny">Allow and Deny</a></li>
  
            <li><a href="#satisfy">Satisfy</a></li>
          </ul>
          <br />
        </li>
  
        <li><a href="#summary">Summary</a></li>
      </ul>
      <!--End of Table of Child-Links-->
      <hr />
  
      <h1><a name="auth"></a><br />
       Authentication, Authorization, and Access Control</h1>
  
      <h1><a name="intro">Introduction</a></h1>
  
      <p>Apache has three distinct ways of dealing with the question
      of whether a particular request for a resource will result in
      that resource actually be returned. These criteria are called
      <i>Authorization</i>, <i>Authentication</i>, and <i>Access
      control</i>.</p>
  
      <p>Authentication is any process by which you verify that
      someone is who they claim they are. This usually involves a
      username and a password, but can include any other method of
      demonstrating identity, such as a smart card, retina scan,
      voice recognition, or fingerprints. Authentication is
      equivalent to showing your drivers license at the ticket
      counter at the airport.</p>
  
      <p>Authorization is finding out if the person, once identified,
      is permitted to have the resource. This is usually determined
      by finding out if that person is a part of a particular group,
      if that person has paid admission, or has a particular level of
      security clearance. Authorization is equivalent to checking the
      guest list at an exclusive party, or checking for your ticket
      when you go to the opera.</p>
  
      <p>Finally, access control is a much more general way of
      talking about controlling access to a web resource. Access can
      be granted or denied based on a wide variety of criteria, such
      as the network address of the client, the time of day, the
      phase of the moon, or the browser which the visitor is using.
      Access control is analogous to locking the gate at closing
      time, or only letting people onto the ride who are more than 48
      inches tall - it's controlling entrance by some arbitrary
      condition which may or may not have anything to do with the
      attributes of the particular visitor.</p>
  
      <p>Because these three techniques are so closely related in
      most real applications, it is difficult to talk about them
      separate from one another. In particular, authentication and
      authorization are, in most actual implementations,
      inextricable.</p>
  
      <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 tutorial will help you make sure that the people that see
      those pages are the people that you wanted to see them.</p>
  
      <h1><a name="basic"></a>Basic authentication</h1>
  
      <p>As the name implies, basic authentication is the simplest
      method of authentication, and for a long time was the most
      common authentication method used. However, other methods of
      authentication have recently passed basic in common usage, due
      to usability issues that will be discussed in a minute.</p>
  
      <h2><a name="basicworks"></a><br />
       How basic authentication works</h2>
  
      <p>When a particular resource has been protected using basic
      authentication, Apache sends a <tt>401 Authentication
      Required</tt> header with the response to the request, in order
      to notify the client that user credentials must be supplied in
      order for the resource to be returned as requested.</p>
  
      <p>Upon receiving a <tt>401</tt> response header, the client's
      browser, if it supports basic authentication, will ask the user
      to supply a username and password to be sent to the server. If
      you are using a graphical browser, such as Netscape or Internet
      Explorer, what you will see is a box which pops up and gives
      you a place to type in your username and password, to be sent
      back to the server. If the username is in the approved list,
      and if the password supplied is correct, the resource will be
      returned to the client.</p>
  
      <p>Because the HTTP protocol is stateless, each request will be
      treated in the same way, even though they are from the same
      client. That is, every resource which is requested from the
      server will have to supply authentication credentials over
      again in order to receive the resource.</p>
  
      <p>Fortunately, the browser takes care of the details here, so
      that you only have to type in your username and password one
      time per browser session - that is, you might have to type it
      in again the next time you open up your browser and visit the
      same web site.</p>
  
      <p>Along with the <tt>401</tt> response, certain other
      information will be passed back to the client. In particular,
      it sends a name which is associated with the protected area of
      the web site. This is called the <i>realm</i><a id="11257"
      name="11257"></a>, or just the authentication name. The client
      browser caches the username and password that you supplied, and
      stores it along with the authentication realm, so that if other
      resources are requested from the same realm, the same username
      and password can be returned to authenticate that request
      without requiring the user to type them in again. This cacheing
      is usually just for the current browser session, but some
      browsers allow you to store them permanently, so that you never
      have to type in your password again.</p>
  
      <p>The authentication name, or realm, will appear in the pop-up
      box, in order to identify what the username and password are
      being requested for.</p>
  
      <h2><a name="basicconfig"></a>
       Configuration: Protecting content with basic
      authentication</h2>
  
      <p>There are two configuration steps which you must complete in
      order to protect a resource using basic authentication. Or
      three, depending on what you are trying to do.</p>
  
      <ol>
        <li>Create a password file</li>
  
        <li>Set the configuration to use this password file</li>
  
        <li>Optionally, create a group file</li>
      </ol>
  
      <h3><a name="htpasswd"></a><br />
       Create a password file</h3>
  
      <p>In order to determine whether a particular username/password
      combination is valid, the username and password supplied by the
      user will need to be compared to some authoritative listing of
      usernames and password. This is the password file, which you
      will need to create on the server side, and populate with valid
      users and their passwords.</p>
  
      <p>Because this file contains sensitive information, it should
      be stored outside of the document directory. Although, as you
      will see in a moment, the passwords are encrypted in the file,
      if a cracker were to gain access to the file, it would be an
      aid in their attempt to figure out the passwords. And, because
      people tend to be sloppy with the passwords that they choose,
      and use the same password for web site authentication as for
      their bank account, this potentially be a very serious breach
      of security, even if the content on your web site is not
      particularly sensitive.</p>
  
      <p><b>Caution:</b> Encourage your users to use a different
      password for your web site than for other more essential
      things. For example, many people tend to use two passwords -
      one for all of their extremely important things, such as the
      login to their desktop computer, and for their bank account,
      and another for less sensitive things, the compromise of which
      would be less serious.</p>
  
      <p>To create the password file, use the <tt>htpasswd</tt>
      utility that came with Apache. This will be located in the
      <tt>bin</tt> directory of wherever you installed Apache. For
      example, it will probably be located at
      <tt>/usr/local/apache/bin/htpasswd</tt> if you installed Apache
      from source.</p>
  
      <p>To create the file, type:</p>
  <pre>
  htpasswd -c /usr/local/apache/passwd/password username
  </pre>
  
      <p><tt>htpasswd</tt> 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>Note that in the example shown, a password file is being
      created containing a user called <tt>rbowen</tt>, and this
      password file is being placed in the location
      <tt>/usr/local/apache/passwd/passwords</tt>. You will
      substitute the location, and the username, which you want to
      use to start your password file.</p>
  
      <p>If <tt>htpasswd</tt> is not in your path, you will have to
      type the full path to the file to get it to run. That is, in
      the example above, you would replace <tt>htpasswd</tt> with
      <tt>/usr/local/apache/bin/htpasswd</tt></p>
  
      <p>The <tt>-c</tt> flag is used only when you are creating a
      new file. After the first time, you will omit the <tt>-c</tt>
      flag, when you are adding new users to an already-existing
      password file.</p>
  <pre>
  htpasswd /usr/local/apache/passwd/passwords sungo
  </pre>
  
      <p>The example just shown will add a user named <tt>sungo</tt>
      to a password file which has already been created earlier. As
      before, you will be asked for the password at the command line,
      and then will be asked to confirm the password by typing it
      again.</p>
  
      <p><b>Caution:</b> Be very careful when you add new users to an
      existing password file that you don't use the <tt>-c</tt> flag
      by mistake. Using the <tt>-c</tt> flag will create a new
      password file, even if you already have an existing file of
      that name. That is, it will remove the contents of the file
      that is there, and replace it with a new file containing only
      the one username which you were adding.</p>
  
      <p>The password is stored in the password file in encrypted
      form, so that users on the system will not be able to read the
      file and immediately determine the passwords of all the users.
      Nevertheless, you should store the file in as secure a location
      as possible, with whatever minimum permissions on the file so
      that the web server itself can read the file. For example, if
      your server is configured to run as user <tt>nobody</tt> and
      group <tt>nogroup</tt>, then you should set permissions on the
      file so that only that user can read the file:</p>
  <pre>
  chown nobody.nogroup /usr/local/apache/passwd/passwords
  chmod 640 /usr/local/apache/passwd/passwords
  </pre>
  
      <p>On Windows, a similar precaution should be taken, changing
      the ownership of the password file to the web server user, so
      that other users cannot read the file.</p>
  
      <h3><a name="htpasswdconfig"></a><br />
       Set the configuration to use this password file</h3>
  
      <p>Once you have created the password file, you need to tell
      Apache about it, and tell Apache to use this file in order to
      require user credentials for admission. This configuration is
      done with the following directives:</p>
  
      <table cellpadding="3">
        <tr>
          <td align="LEFT">AuthType</td>
  
          <td align="LEFT" valign="TOP" width="360">Authentication
          type being used. In this case, it will be set to
          <tt>Basic</tt></td>
        </tr>
  
        <tr>
          <td align="LEFT">AuthName</td>
  
          <td align="LEFT" valign="TOP" width="360">The
          authentication realm or name</td>
        </tr>
  
        <tr>
          <td align="LEFT">AuthUserFile</td>
  
          <td align="LEFT" valign="TOP" width="360">The location of
          the password file</td>
        </tr>
  
        <tr>
          <td align="LEFT">AuthGroupFile</td>
  
          <td align="LEFT" valign="TOP" width="360">The location of
          the group file, if any</td>
        </tr>
  
        <tr>
          <td align="LEFT">Require</td>
  
          <td align="LEFT" valign="TOP" width="360">The
          requirement(s) which must be satisfied in order to grant
          admission</td>
        </tr>
      </table>
  
      <p>These directives may be placed in a <tt>.htaccess</tt> file
      in the particular directory being protected, or may go in the
      main server configuration file, in a <tt>&lt;Directory&gt;</tt>
      section, or other scope container.</p>
  
      <p>The example shown below defines an authentication realm
      called ``By Invitation Only''. The password file located at
      <tt>/usr/local/apache/passwd/passwords</tt> will be used to
      verify the user's identity. Only users named <tt>rbowen</tt> or
      <tt>sungo</tt> will be granted access, and even then only if
      they provide a password which matches the password stored in
      the password file.</p>
  <pre>
  AuthType Basic
  AuthName "By Invitation Only"
  AuthUserFile /usr/local/apache/passwd/passwords
  Require user rbowen sungo
  </pre>
  
      <p>The phrase ``By Invitation Only'' will be displayed in the
      password pop-up box, where the user will have to type their
      credentials.</p>
  
      <p>You will need to restart your Apache server in order for the
      new configuration to take effect, if these directives were put
      in the main server configuration file. Directives placed in
      <tt>.htaccess</tt> files take effect immediately, since
      <tt>.htaccess</tt> files are parsed each time files are
      served.</p>
  
      <p>The next time that you load a file from that directory, you
      will see the familiar username/password dialog box pop up,
      requiring that you type the username and password before you
      are permitted to proceed.</p>
  
      <p>Note that in addition to specifically listing the users to
      whom you want to grant access, you can specify that any valid
      user should be let in. This is done with the
      <tt>valid-user</tt> keyword:</p>
  <pre>
  Require valid-user
  </pre>
  
      <h3><a name="basicgroupfile"></a><br />
       Optionally, create a group file</h3>
  
      <p>Most of the time, you will want more than one, or two, or
      even a dozen, people to have access to a resource. You want to
      be able to define a group of people that have access to that
      resource, and be able to manage that group of people, adding
      and removing members, without having to edit the server
      configuration file, and restart Apache, each time.</p>
  
      <p>This is handled using authentication groups. An
      authentication group is, as you would expect, a group name
      associated with a list of members. This list is stored in a
      group file, which should be stored in the same location as the
      password file, so that you are able to keep track of these
      things.</p>
  
      <p>The format of the group file is exceedingly simple. A group
      name appears first on a line, followed by a colon, and then a
      list of the members of the group, separated by spaces. For
      example:</p>
  <pre>
  authors: rich daniel allan
  </pre>
  
      <p>Once this file has been created, you can <tt>Require</tt>
      that someone be in a particular group in order to get the
      requested resource. This is done with the
      <tt>AuthGroupFile</tt> directive, as shown in the following
      example.</p>
  <pre>
  AuthType Basic
  AuthName "Apache Admin Guide Authors"
  AuthUserFile /usr/local/apache/passwd/passwords
  AuthGroupFile /usr/local/apache/passwd/groups
  Require group authors
  </pre>
  
      <p>The authentication process is now one step more involved.
      When a request is received, and the requested username and
      password are supplied, the group file is first checked to see
      if the supplied username is even in the required group. If it
      is, then the password file will be checked to see if the
      username is in there, and if the supplied password matches the
      password stored in that file. If any of these steps fail,
      access will be forbidden.</p>
  
      <h2><a name="basicfaq"></a><br />
       Frequently asked questions about basic auth</h2>
  
      <p>The following questions tend to get asked very frequently
      with regard to basic authentication. It should be understood
      that basic authentication is very basic, and so is limited to
      the set of features that has been presented above. Most of the
      more interesting things that people tend to want, need to be
      implemented using some alternate authentication scheme.</p>
  
      <h3><a name="logout"></a><br />
       How do I log out?</h3>
  
      <p>Since browsers first started implementing basic
      authentication, website administrators have wanted to know how
      to let the user log out. Since the browser caches the username
      and password with the authentication realm, as described
      earlier in this tutorial, this is not a function of the server
      configuration, but is a question of getting the browser to
      forget the credential information, so that the next time the
      resource is requested, the username and password must be
      supplied again. There are numerous situations in which this is
      desirable, such as when using a browser in a public location,
      and not wishing to leave the browser logged in, so that the
      next person can get into your bank account.</p>
  
      <p>However, although this is perhaps the most frequently asked
      question about basic authentication, thus far none of the major
      browser manufacturers have seen this as being a desirable
      feature to put into their products.</p>
  
      <p>Consequently, the answer to this question is, you can't.
      Sorry.</p>
  
      <h3><a name="passworddialog"></a><br />
       How can I change what the password box looks like?</h3>
  
      <p>The dialog that pops up for the user to enter their username
      and password is ugly. It contains text that you did not
      indicate that you wanted in there. It looks different in
      Internet Explorer and Netscape, and contains different text.
      And it askes for fields that the user might not understand -
      for example, Netscape asks the user to type in their ``User
      ID'', and they might not know what that means. Or, you might
      want to provide additional explanatory text so that the user
      has a better idea what is going on.</p>
  
      <p>Unfortunately, these things are features of the browser, and
      cannot be controlled from the server side. If you want the
      login to look different, then you will need to implement your
      own authenticatin scheme. There is no way to change what this
      login box looks like if you are using basic authentication.</p>
  
      <h3><a name="persistpass"></a><br />
       How to I make it not ask me for my password the next
      time?</h3>
  
      <p>Because most browsers store your password information only
      for the current browser session, when you close your browser it
      forgets your username and password. So, when you visit the same
      web site again, you will need to re-enter your username and
      password.</p>
  
      <p>There is nothing that can be done about this on the server
      side.</p>
  
      <p>However, the most recent versions of the major browsers
      contain the ability to remember your password forever, so that
      you never have to log in again. While it is debatable whether
      this is a good idea, since it effectively overrides the entire
      point of having security in the first place, it is certainly
      convenient for the user, and simplifies the user
      experience.</p>
  
      <h3><a name="passwordtwice"></a><br />
       Why does it sometimes ask me for my password twice?</h3>
  
      <p>When entering a password-protected web site for the first
      time, you will occasionally notice that you are asked for your
      password twice. This may happen immediately after you entered
      the password the first time, or it may happen when you click on
      the first link after authenticating the first time.</p>
  
      <p>This happens for a very simple, but nonetheless confusing,
      reason, again having to do with the way that the browser caches
      the login information.</p>
  
      <p>Login information is stored on the browser based on the
      authentication realm, specified by the <tt>AuthName</tt>
      directive, and by the server name. In this way, the browser can
      distinguish between the <tt>Private</tt> authentication realm
      on one site and on another. So, if you go to a site using one
      name for the server, and internal links on the server refer to
      that server by a different name, the browser has no way to know
      that they are in fact the same server.</p>
  
      <p>For example, if you were to visit the URL
      <tt>http://example.com/private/</tt>, which required
      authentication, your browser would remember the supplied
      username and password, associated with the hostname
      <tt>example.com</tt>. If, by virtue of an internal redirect, or
      fully-qualified HTML links in pages, you are then sent to the
      URL <tt>http://www.example.com/private/</tt>, even though this
      is really exactly the same URL, the browser does not know this
      for sure, and is forced to request the authentication
      information again, since <tt>example.com</tt> and
      <tt>www.example.com</tt> are not exactly the same hostname.
      Your browser has no particular way to know that these are the
      same web site.</p>
  
      <h2><a name="basiccaveat"></a><br />
       Security caveat</h2>
  
      <p>Basic authentication should not be considered secure for any
      particularly rigorous definition of secure.</p>
  
      <p>Although the password is stored on the server in encrypted
      format, it is passed from the client to the server in plain
      text across the network. Anyone listening with any variety of
      packet sniffer will be able to read the username and password
      in the clear as it goes across.</p>
  
      <p>Not only that, but remember that the username and password
      are passed with every request, not just when the user first
      types them in. So the packet sniffer need not be listening at a
      particularly strategic time, byt just be listening for long
      enough to see any request come across the wire.</p>
  
      <p>And, in addition to that, the content itself is also going
      across the network in the clear, and so if the web site
      contains sensitive information, the same packet sniffer would
      have access to that information as it went past, even if the
      username and password were not used to gain direct access to
      the web site.</p>
  
      <p>Don't use basic authentication for anything that requires
      real security. It is a detriment for most users, since very few
      people will take the trouble, or have the necessary software
      and/or equipment, to find out passwords. However, if someone
      had a desire to get in, it would take very little for them to
      do so.</p>
  
      <h1><a name="digest"></a>Digest authentication</h1>
  
      <p>Addressing one of the security caveats of basic
      authentication, digest authentication provides an alternate
      method for protecting your web content. However, it to has a
      few caveats.</p>
  
      <h2><a name="digestworks">How digest auth works</a></h2>
  
      <p>Digest authentication is implemeted by the module
      <tt>mod_auth_digest</tt>. There is an older module,
      <tt>mod_digest</tt>, which implemented an older version of the
      digest authentication specification, but which will probably
      not work with newer browsers.</p>
  
      <p>Using digest authentication, your password is never sent
      across the network in the clear, but is always transmitted as
      an MD5 digest of the user's password. In this way, the password
      cannot be determined by sniffing network traffic.</p>
  
      <p>The full specification of digest authentication can be seen
      in the internet standards document RFC 2617, which you can see
      at <tt>http://www1.ics.uci.edu/pub/ietf/http/rfc2617.txt</tt>.
      Additional information and resources about MD5 can be found at
      <tt>http://userpages.umbc.edu/&nbsp;mabzug1/cs/md5/md5.html</tt></p>
  
      <h2><a name="digestconfig"></a>Configuration: 
      Protecting content with digest authentication</h2>
  
      <p>The steps for configuring your server for digest
      authentication are very similar for those for basic
      authentication.</p>
  
      <ol>
        <li>Create the password file</li>
  
        <li>Set the configuration to use this password file</li>
  
        <li>Optionally, create a group file</li>
      </ol>
  
      <h3><a name="htdigest"></a>Creating a password file</h3>
  
      <p>As with basic authentication, a simple utility is provided
      to create and maintain the password file which will be used to
      detmine whether a particular user's name and password are
      valid. This utility is called <tt>htdigest</tt>, and will be
      located in the <tt>bin</tt> diretory of wherever you installed
      Apache. If you installed Apache from some variety of package
      manager, <tt>htdigest</tt> is likely to have been placed
      somewhere in your path.</p>
  
      <p>To create a new digest password file, type:</p>
  <pre>
  htdigest -c /usr/local/apache/passwd/digest realm username
  </pre>
  
      <p><tt>htdigest</tt> will ask you for the desired password, and
      then ask you to type it again to confirm it.</p>
  
      <p>Note that the realm for which the authentication will be
      required is part of the argument list.</p>
  
      <p>Once again, as with basic authentication, you are encouraged
      to place the generated file somewhere outside of the document
      directory.</p>
  
      <p>And, as with the <tt>htpasswd</tt> utility, the <tt>-c</tt>
      flag creates a new file, or, if a file of that name already
      exists, deletes the contents of that file and generates a new
      file in its place. Omit the <tt>-c</tt> flag in order to add
      new user information to an existing password file.</p>
  
      <h3><a name="htdigestconfig"></a>Set the configuration
      to use this password file</h3>
  
      <p>Once you have created a password file, you need to tell
      Apache about it in order to start using it as a source of
      authenticated user inormation. This configuration is done with
      the following directives:</p>
  
      <table cellpadding="3">
        <tr>
          <td align="LEFT">AuthType</td>
  
          <td align="LEFT" valign="TOP" width="360">Authentication
          type being used. In this case, it will be set to
          <tt>Digest</tt></td>
        </tr>
  
        <tr>
          <td align="LEFT">AuthName</td>
  
          <td align="LEFT" valign="TOP" width="360">The
          authentication realm or name</td>
        </tr>
  
        <tr>
          <td align="LEFT">AuthDigestFile</td>
  
          <td align="LEFT" valign="TOP" width="360">The location of
          the password file</td>
        </tr>
  
        <tr>
          <td align="LEFT">AuthDigestGroupFile</td>
  
          <td align="LEFT" valign="TOP" width="360">Location of the
          group file, if any</td>
        </tr>
  
        <tr>
          <td align="LEFT">Require</td>
  
          <td align="LEFT" valign="TOP" width="360">The
          requirement(s) which must be satisfied in order ot grant
          admission</td>
        </tr>
      </table>
  
      <p>These directives may be places in a <tt>.htaccess</tt> file
      in the particular directory being protected, or may go in the
      main server configuration file, in a <tt>&lt;Directory&gt;</tt>
      section, or another scope container.</p>
  
      <p>The following example defines an authentication realm called
      "Private". The password file located at
      <tt>/usr/local/apache/passwd/digest</tt> will be used to verify
      the user's identity. Only users named <tt>drbacchus</tt> or
      <tt>dorfl</tt> will be granted access, if they provide a
      password that patches the password stored in the password
      file.</p>
  <pre>
  AuthType Digest
  AuthName "Private"
  AuthDigestFile /usr/local/apache/passwd/digest
  Require user drbacchus dorfl
  </pre>
  
      <p>The phrase "Private" will be displayed in the password
      pop-up box, where the user will have to type their
      credentials.</p>
  
      <h3><a name="digestgroup"></a>Optionally, create a group file</h3>
  
      <p>As you have observed, there are not many differences between
      this configuration process and that required by basic
      authentication, described in the previous section. This is true
      also of group functionality. The group file used for digest
      authentication is exactly the same as that used for basic
      authentication. That is to say, lines in the group file consist
      the name of the group, a colon, and a list of the members of
      that group. For example:</p>
  <pre>
  admins: jim roy ed anne
  </pre>
  
      <p>Once this file has been created, you can <tt>Require</tt>
      that someone be in a particular group in order to get the
      requested resource. This is done with the
      <tt>AuthDigestGroupFile</tt> directive, as shown in the
      following example.</p>
  <pre>
  AuthType Digest
  AuthName "Private"
  AuthDigestFile /usr/local/apache/passwd/digest
  AuthDigestGroupFile /usr/local/apache/passwd/digest.groups
  Require group admins
  </pre>
  
      <p>The authentication process is the same as that used by basic
      authentication. It is first verified that the user is in the
      required group, and, if this is true, then the password is
      verified.</p>
  
      <h2><a name="digestcaveat">Caveats</a></h2>
  
      <p>Before you leap into using digest authentication instead of
      basic authentication, there are a few things that you should
      know about.</p>
  
      <p>Most importantly, you need to know that, although digest
      authentication has this great advantage that you don't send
      your password across the network in the clear, it is not
      supported by all major browsers in use today, and so you should
      not use it on a web site on which you cannot control the
      browsers that people will be using, such as on your intranet
      site. In particular, Opera 4.0 or later, Microsoft Internet
      Explorer 5.0 or later, and Amaya support digest authentication,
      while Netscape, Mozilla, and various other browsers do not.</p>
  
      <p>Next, with regard to security considerations, you should
      understand two things. Although your password is not passed in
      the clear, all of your data is, and so this is a rather small
      measure of security. And, although your password is not really
      sent at all, but a digest form of it, someone very familiar
      with the workings of HTTP could use that information - just
      your digested password - and use that to gain access to the
      content, since that digested password is really all the
      information required to access the web site.</p>
  
      <p>The moral of this is that if you have content that really
      needs to be kept secure, use SSL.</p>
  
      <h1><a name="database">Database authentication
      modules</a></h1>
  
      <p>Basic authentication and digest authentication both suffer
      from the same major flaw. They use text files to store the
      authentication information. The problem with this is that
      looking something up in a text file is very slow. It's rather
      like trying to find something in a book that has no index. You
      have to start at the beginning, and work through it one page at
      a time until you find what you are looking for. Now imagine
      that the next time you need to find the same thing, you don't
      remember where it was before, so you have to start at the
      beginning again, and work through one page at a time until you
      find it again. And the next time. And the time after that.</p>
  
      <p>Since HTTP is stateless, authentication has to be verified
      every time that content is requested. And so every time a
      document is accessed which is secured with basic or digest
      authentication, Apache has to open up those text password files
      and look through them one line at a time, until it finds the
      user that is trying to log in, and verifies their password. In
      the worst case, if the username supplied is not in there at
      all, every line in the file will need to be checked. On
      average, half of the file will need to be read before the user
      is found. This is very slow.</p>
  
      <p>While this is not a big problem for small sets of users,
      when you get into larger numbers of users (where "larger" means
      a few hundred) this becomes prohibitively slow. In many cases,
      in fact, valid username/password combinations will get rejected
      because the authentication module just had to spend so much
      time looking for the username in the file that Apache will just
      get tired of waiting and return a failed authentication.</p>
  
      <p>In these cases, you need an alternative, and that
      alternative is to use some variety of database. Databases are
      optimized for looking for a particular piece of information in
      a very large data set. It builds indexes in order to rapidly
      locate a particular record, and they have query languages for
      swiftly locating records that match particular criteria.</p>
  
      <p>There are numerous modules available for Apache to
      authenticate using a variety of different databases. In this
      section, we'll just look at two modules which ship with Apache.
      </p>
  
      <h2><a name="modauthdb"></a>mod_auth_db and mod_auth_dbm</h2>
  
      <p><tt>mod_auth_db</tt> and <tt>mod_auth_dbm</tt> are modules
      which lets you keep your usernames and passwords in DB or DBM
      files. There are few practical differences between DB files and
      DBM files. And, on some operating systems, such as various
      BSDs, and Linux, they are exactly the same thing. You should
      pick whichever of the two modules makes the most sense on your
      particular platform of choice. If you do not have DB support on
      your platforn, you may need to install it. You download an
      implementation of DB at <tt>http://www.sleepycat.com/</tt>. <a
      id="11415" name="11415"></a></p>
  
      <h2><a name="dbfiles"></a>Berkeley DB files</h2>
  
      <p>DB files, also known as Berkeley database files, are the
      simplest form of database, and are rather ideally suited for
      the sort of data that needs to be stored for HTTP
      authentication. DB files store key/value pairs. That is, the
      name of a variable, and the value of that variable. While other
      databases allow the storage of many fields in a given record, a
      DB file allows only this pairing of key and value.<a
      name="foot1_return" href="#foot1"><sup>21.1</sup></a> This is ideal for
      authentication, which requires only the pair of a username and
      password.</p>
  
      <h2><a name="installauthdb">Installing mod_auth_db</a></h2>
      <tt>mod_auth_db!installing</tt> 
  
      <p>For the purposes of this tutorial, we'll talk about
      installing and configuring <tt>mod_auth_db</tt>. However,
      everything that is said here can be directly applied to
      <tt>mod_auth_dbm</tt> by simply replacing 'db' with 'dbm' and
      'DB' with 'DBM' in the various commands, file names, and
      directives.</p>
  
      <p>Since <tt>mod_auth_db</tt> is not compiled in by default,
      you will need to rebuild Apache in order to get the
      functionality, unless you built in everything when we started.
      Note that if you installed Apache with shared object
      support, you may be able to just build the module and load it
      in to Apache.</p>
  
      <p>To build Apache from scratch with <tt>mod_auth_db</tt> built
      in, use the following <tt>./configure</tt> line in your apache
      source code directory.</p>
  <pre>
  ./configure --enable-module=auth_db
  </pre>
  
      <p>Or, if you had a more complex <tt>configure</tt> command
      line, you can just add the <tt>-enable-module=auth_db</tt>
      option to that command line, and you'll get
      <tt>mod_auth_db</tt> built into your server.</p>
  
      <h2><a name="authdbconfig">Protecting a directory with
      mod_auth_db</a></h2>
  
      <p>Once you have compiled the <tt>mod_auth_db</tt> module, and
      loaded it into your web server, you'll find that there's very
      little difference between using regular authentication and
      using <tt>mod_auth_db</tt> authentication. The procedure is the
      same as that we went through with basic and digest
      authentication:</p>
  
      <ol>
        <li>Create the user file.</li>
  
        <li>Configure Apache to use that file for
        authentication.</li>
  
        <li>Optionally, create a group file.</li>
      </ol>
  
      <h3><a name="dbmmanage"></a>Create the user file</h3>
  
      <p>The user file for authentication is, this time, not a flat
      text file, but is a DB file<a name="foot2_return"
      href="#foot2"><sup>21.2</sup></a>. Fortunately, once again,
      Apache provides us with a simple utility for the purpose of
      managing this user file. This time, the utility is called
      <tt>dbmmanage</tt>, and will be located in the <tt>bin</tt>
      subdirectory of wherever you installed Apache.</p>
  
      <p><tt>dbmmanage</tt> is somewhat more complicated to use than
      <tt>htpasswd</tt> or <tt>htdigest</tt>, but it is still fairly
      simple. The syntax which you will usually be using is as
      follows:</p>
  <pre>
  dbmmanage passwords.db adduser montressor
  </pre>
  
      <p>As with <tt>htpasswd</tt>, you will at this point be
      prompted for a password, and then asked to confirm that
      password by typing it again. The main difference here is that
      rather than a text file being created, you are creating a
      binary file containing the information that you have
      supplied.</p>
  
      <p>Type <tt>dbmmanage</tt> with no arguments to get the full
      list of options available with this utility.</p>
  
      <h3><a name="perl_dbfile">Creating your user file with
      Perl</a></h3>
  
      <p>Note that, if you are so inclined, you can manage your user
      file with Perl, or any other language which has a DB-file
      module, for interfacing with this type of database. This covers
      a number of popular programming languages.</p>
  
      <p>The following Perl code, for example, will add a user
      'rbowen', with password 'mypassword', to your password
      file:</p>
  <pre>
  use DB_File;
  tie %database, 'DB_File', "passwords.dat"
      or die "Can't initialize database: $!\n";
  
  $username = 'rbowen';
  $password = 'mypassword';
  @chars=(0..9,'a'..'z');
  $salt = '', map { $chars[int rand @chars] } (0..1);
  
  $crypt = crypt($password, $salt);
  $database{$username} = $crypt;
  
  untie %database;
  </pre>
  
      <p>As you can imagine, this makes it very simple to write tools
      to manage the user and password information stored in these
      files.</p>
  
      <p>Passwords are stored in Unix <tt>crypt</tt> format, just as
      they were in the "regular" password files. The 'salt' that is
      created in the middle there is part of the process, cenerating
      a random starting point for that encryption. The technique
      being used is called a 'tied hash'. The idea is to tie a
      built-in data structure to the contents of the file, such that
      when the data structure is changed, the file is automatically
      modified at the same time.</p>
  
      <h3><a name="authdbuserfile"></a>Configuration Apache
      to use this password file</h3>
  
      <p>Once you have created the password file, you need to tell
      Apache about it, and tell Apache to use this file to verify
      user credentials. This configuration will look almost the same
      as that for basic authentication. This configuration can go in
      a <tt>.htaccess</tt> file in the directory to be protected, or
      can go in the main server configuration, in a
      <tt>&lt;Directory&gt;</tt> section, or other scope container
      directive.</p>
  
      <p>The configuration will look something like the
      following:</p>
  <pre>
  AuthName "Members Only"
  AuthType Basic
  AuthDBUserFile /usr/local/apache/passwd/passwords.dat
  require user rbowen
  </pre>
  
      <p>Now, users accessing the directory will be required to
      authenticate against the list of valid users who are in
      <tt>/usr/local/apache/passwd/passwords.dat</tt>.</p>
  
      <h3><a name="authdbgroupfile"></a><br />
       Optionally, create a group file</h3>
  
      <p>As mentioned earlier, DB files store a key/value pair. In
      the case of group files, the key is the name of the user, and
      the value is a comma-separated list of the groups to which the
      user belongs.</p>
  
      <p>While this is the opposite of the way that group files are
      stored elsewhere, note that we will primarily be looking up
      records based on the username, so it is more efficient to index
      the file by username, rather than by the group name.</p>
  
      <p>Groups can be added to your group file using
      <tt>dbmmanage</tt> and the <tt>add</tt> command:</p>
  <pre>
  dbmmanage add groupfile rbowen one,two,three
  </pre>
  
      <p>In the above example, <tt>groupfile</tt> is the literal name
      of the group file, <tt>rbowen</tt> is the user being added, and
      <tt>one</tt>, <tt>two</tt>, and <tt>three</tt> are names of
      three groups to which this user belongs.</p>
  
      <p>Once you have your groups in the file, you can require a
      group in the regular way:</p>
  <pre>
  AuthName "Members Only"
  AuthType Basic
  AuthDBUserFile /usr/local/apache/passwd/passwords.dat
  AuthDBGroupFile /usr/local/apache/passwd/groups.dat
  require group three
  </pre>
  
      <p>Note that if you want to use the same file for both password
      and group information, you can do so, but this is a little more
      complicated to manage, as you have to encrypt the password
      yourself before you feed it to the <tt>dbmmanage</tt>
      utility.</p>
  
      <h1><a name="access"></a>Access control</h1>
  
      <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. Restricting access based on something other than
      the identity of the user is generally referred to as <i>Access
      Control</i>.</p>
  
      <h2><a name="allowdeny"></a>Allow and Deny</h2>
  
      <p>The <tt>Allow</tt> and <tt>Deny</tt> directives let you
      allow and deny access based on the host name, or host address,
      of the machine requesting a document. The directive goes
      hand-in-hand with these is the <tt>Order</tt> directive, which
      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 <i>address</i> is an IP address (or a partial IP
      address) or a fully qualified domain name (or a partial domain
      name).</p>
  
      <p>For example, if you have someone spamming your message
      board, and you want to keep them out, you could do the
      following: <a id="11494" name="11494"></a></p>
  <pre>
  deny from 205.252.46.165
  </pre>
  
      <p>Visitors coming from that address will not be able to see
      the content behind this directive. If, instead, you have a
      machine name, rather than an IP address, you can use that. <a
      id="11497" name="11497"></a></p>
  <pre>
  deny from dc.numbersusa.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
  deny from ke
  </pre>
  
      <p>Using <tt>Order</tt> will let you be sure that you are
      actually restricting things to the group that you want to let
      in, by combining a <tt>deny</tt> and an <tt>allow</tt>
      directive:</p>
  <pre>
  Order Deny,Allow
  Deny from all
  Allow from hostname.example.com
  </pre>
  
      <p>Listing just the <tt>allow</tt> directive would not do what
      you want, because it will let users from that host in, in
      addition to letting everyone in. What you want is to let in
      <i>only</i> users from that host.</p>
  
      <h2><a name="satisfy"></a>Satisfy</h2>
  
      <p>The <tt>Satisfy</tt> directive can be used to specify that
      several criteria may be considered when trying to decide if a
      particular user will be granted admission. <tt>Satisfy</tt> can
      take as an argument one of two options - <tt>all</tt> or
      <tt>any</tt>. By default, it is assumed that the value is
      <tt>all</tt>. This means that if several criteria are
      specified, then all of them must be met in order for someone to
      get in. However, if set to <tt>any</tt>, then several criteria
      may be specified, but if the user satisfies any of these, then
      they will be granted entrance.</p>
  
      <p>A very good example of this is using access control to
      assure that, although a resource is password protected from
      outside your network, all hosts inside the network will be
      given free access to the resource. This would be accomplished
      by using the <tt>Satisfy</tt> directive, as shown below.</p>
  <pre>
  &lt;Directory /usr/local/apache/htdocs/sekrit&gt;
    AuthType Basic
    AuthName intranet
    AuthUserFile /www/passwd/users
    AuthGroupFile /www/passwd/groups
    Require group customers
    Allow from internal.com
    Satisfy any
  &lt;/Directory&gt;
  </pre>
  
      <p>In this scenario, users will be let in ir they either have a
      password, or if they are in the internal network.</p>
  
      <h1><a name="summary">Summary</a></h1>
  
      <p>The various authentication modules provide a number of ways
      to restrict access to your host based on the identity of the
      user. They offere a somewhat standard interface to this
      functionality, but provide different back-end mechanisms for
      actually authenticating the user.</p>
  
      <p>And the access control mechanism allows you to restrict
      access based on criteria unrelated to the identity of the
      user.<br />
      </p>
      <hr />
  
      <h4>Footnotes</h4>
  
      <dl>
        <dt><a name="foot1">... value.</a><a
        href="#foot1_return"><sup>21.1</sup></a></dt>
  
        <dd>There are actually a number of implementations that get
        around this limitation. MLDBM is one of them, for example.
        However, for the purposes of this discussion, we'll just deal
        with standard Berkeley DB, which is likeley to have shipped
        with whatever operating system you are already running.</dd>
  
        <dt><a name="foot2">... file</a><a
        href="#foot2_return"><sup>21.2</sup></a></dt>
  
        <dd>Or, if you are using mod_auth_dbm, a DBM file.</dd>
      </dl>
      <hr />
  
    </body>
  </html>
  
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org


Mime
View raw message