docs/manual/howto/auth.xml.ja

   1 <?xml version="1.0" encoding="UTF-8" ?>
   2 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
   3 <?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
   4 <!-- English Revision: 479777:728126 (outdated) -->
   5
   6 <!--
   7  Licensed to the Apache Software Foundation (ASF) under one or more
   8  contributor license agreements.  See the NOTICE file distributed with
   9  this work for additional information regarding copyright ownership.
  10  The ASF licenses this file to You under the Apache License, Version 2.0
  11  (the "License"); you may not use this file except in compliance with
  12  the License.  You may obtain a copy of the License at
  13
  14      http://www.apache.org/licenses/LICENSE-2.0
  15
  16  Unless required by applicable law or agreed to in writing, software
  17  distributed under the License is distributed on an "AS IS" BASIS,
  18  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  19  See the License for the specific language governing permissions and
  20  limitations under the License.
  21 -->
  22
  23 <manualpage metafile="auth.xml.meta">
  24 <parentdocument href="./">How-To / チュートリアル</parentdocument>
  25
  26 <title>認証、承認、アクセス制御</title>
  27
  28 <summary>
  29     <p>「認証」とは、誰かが自分は誰であるかを主張した場合に、
  30     それを確認するための全過程を指します。「承認」とは、
  31     誰かが行きたい場所に行けるように、あるいは欲しい情報を
  32     得ることができるようにするための全過程を指します。</p>
  33 </summary>
  34
  35 <section id="related"><title>関連するモジュールとディレクティブ</title>
  36 <p>認証と承認の処理に関連する 3 種類のモジュールがあります。
  37 それぞれ少なくともひとつずつ必要です。</p>
  38
  39 <ul>
  40   <li>認証のタイプ (
  41       <directive module="core">AuthType</directive> ディレクティブ参照)
  42     <ul>
  43       <li><module>mod_auth_basic</module></li>
  44       <li><module>mod_auth_digest</module></li>
  45     </ul>
  46   </li>
  47   <li>認証プロバイダ (
  48   <directive module="mod_auth_basic">AuthBasicProvider</directive>,
  49   <directive module="mod_auth_digest">AuthDigestProvider</directive> ディレクティブ参照)
  50
  51     <ul>
  52       <li><module>mod_authn_anon</module></li>
  53       <li><module>mod_authn_dbd</module></li>
  54       <li><module>mod_authn_dbm</module></li>
  55       <li><module>mod_authn_default</module></li>
  56       <li><module>mod_authn_file</module></li>
  57       <li><module>mod_authnz_ldap</module></li>
  58     </ul>
  59   </li>
  60   <li>承認 (
  61       <directive module="core">Require</directive> ディレクティブ参照)
  62     <ul>
  63       <li><module>mod_authnz_ldap</module></li>
  64       <li><module>mod_authz_dbm</module></li>
  65       <li><module>mod_authz_dbm</module></li>
  66       <li><module>mod_authz_default</module></li>
  67       <li><module>mod_authz_groupfile</module></li>
  68       <li><module>mod_authz_host</module></li>
  69       <li><module>mod_authz_owner</module></li>
  70       <li><module>mod_authz_user</module></li>
  71     </ul>
  72   </li>
  73 </ul>
  74
  75   <p>これらのモジュールに加えて、<module>mod_authn_core</module>
  76   と <module>mod_authz_core</module> があります。
  77   この 2 つのモジュールは認証モジュールに共通なコアディレクティブを
  78   実装しています。</p>
  79
  80   <p><module>mod_authnz_ldap</module> は認証プロバイダと承認プロバイダの
  81   両方の機能を持っています。
  82   <module>mod_authz_host</module> はホスト名、IP アドレスや
  83   リクエストの特徴に基づいたアクセス制御を行いますが、
  84   認証プロバイダのシステムの一部ではありません。
  85   mod_access との後方互換性のため、
  86   新しいモジュールの <module>mod_access_compat</module> があります。</p>
  87
  88   <p>様々なアクセス制御の行ない方については、
  89   <a href="access.html">アクセス制御</a>の方法をご覧ください。</p>
  90
  91 </section>
  92
  93 <section id="introduction"><title>はじめに</title>
  94     <p>もし機密の情報や、ごくごく少数グループの人向けの情報を
  95     ウェブサイトに置くのであれば、この文書に書かれている
  96     テクニックを使うことで、そのページを見ている人たちが
  97     望みの人たちであることを確実にできるでしょう。</p>
  98
  99     <p>この文書では、多くの人が採用するであろう、
 100     ウェブサイトの一部分を保護する「一般的な」
 101     方法についてカバーしています。</p>
 102
 103     <note><title>注意</title>
 104     <p>データが本当に機密なのであれば、認証に加えてさらに
 105     <module>mod_ssl</module> を使うと良いでしょう。</p>
 106     </note>
 107 </section>
 108
 109 <section id="theprerequisites"><title>準備</title>
 110     <p>この文書で取り扱われるディレクティブは、
 111     メインサーバ設定ファイル (普通は
 112     <directive module="core" type="section">Directory</directive>
 113     セクション中) か、あるいはディレクトリ毎の設定ファイル
 114     (<code>.htaccess</code> ファイル) かで用います。</p>
 115
 116     <p><code>.htaccess</code> ファイルを用いるのであれば、
 117     これらのファイルに認証用のディレクティブを置けるように
 118     サーバの設定をしないといけないでしょう。これは
 119     <directive module="core">AllowOverride</directive>
 120     ディレクティブで可能になります。
 121     <directive module="core">AllowOverride</directive>
 122     ディレクティブでは、ディレクトリ毎の設定ファイル中に置くことのできる
 123     ディレクティブを、もしあれば、指定します。</p>
 124
 125     <p>認証について話を進めているので、次のような
 126     <directive module="core">AllowOverride</directive>
 127     ディレクティブが必要になるでしょう。</p>
 128
 129     <example>
 130       AllowOverride AuthConfig
 131     </example>
 132
 133     <p>そうでなく、メインサーバ設定ファイルの中に
 134     直接置くのであれば、当然ながらそのファイルへの書き込み
 135     権限を持っていなければならないでしょう。</p>
 136
 137     <p>また、どのファイルがどこに保存されているか知るために、
 138     サーバのディレクトリ構造について少し知っておく
 139     必要があるでしょう。
 140     これはそんなに難しくないので、この文書中で
 141     ディレクトリ構造について知っておく必要がある場面では、
 142     明らかになるようにします。</p>
 143
 144     <p><module>mod_authn_core</module> と <module>mod_authz_core</module>
 145     の両方が httpd バイナリに静的に組み込み済みであるか、httpd.conf
 146     設定ファイルで動的にロードされるかして、httpd に組み込まれていなければ
 147     なりません。これらの二つのモジュールは、設定ファイルのなかで非常に
 148     重要でウェブサーバの認証と承認で使用されるコアディレクティブと
 149     その機能を提供しています。</p>
 150 </section>
 151
 152 <section id="gettingitworking"><title>動作させる</title>
 153     <p>では、サーバ上のあるディレクトリをパスワードで保護する
 154     基本手順を示します。</p>
 155
 156     <p>まずはじめに、パスワードファイルを作ります。
 157     どの認証プロバイダを使うかによって、パスワードファイル生成の手順は
 158     大きく異なります。ここでの例では、手始めにテキストパスワードファイルを
 159     使います。</p>
 160
 161     <p>このパスワードファイルは、ウェブからアクセスできる場所に
 162     置くべきではありません。他の人がパスワードファイルを
 163     ダウンロードできないようにするためです。例えば、
 164     <code>/usr/local/apache/htdocs</code> でドキュメントを
 165     提供しているのであれば、パスワードファイルは
 166     <code>/usr/local/apache/passwd</code>
 167     などに置いた方が良いでしょう。</p>
 168
 169     <p>ファイルを作るためには、Apache 付属の <program>htpasswd</program>
 170     を使います。このコマンドは Apache をどこにインストールしようとも、
 171     インストールディレクトリの <code>bin</code>
 172     ディレクトリ以下に置かれます。サードバーティ製のパッケージで
 173     インストールした場合は、実行パスの中で見つかるでしょう。</p>
 174
 175     <p>ファイルを作るには、次のようにタイプしてください。</p>
 176
 177     <example>
 178       htpasswd -c /usr/local/apache/passwd/passwords rbowen
 179     </example>
 180
 181     <p><program>htpasswd</program> は、パスワードを要求し、その後
 182     確認のためにもう一度入力するように要求してきます。</p>
 183
 184     <example>
 185       # htpasswd -c /usr/local/apache/passwd/passwords rbowen<br />
 186       New password: mypassword<br />
 187       Re-type new password: mypassword<br />
 188       Adding password for user rbowen
 189     </example>
 190
 191     <p>もし <program>htpasswd</program> がパスの中に入っていない場合は、
 192     もちろん、実行するためにプログラムまでのフルパスを
 193     タイプする必要があります。デフォルトのインストール状態であれば、
 194     <code>/usr/local/apache/bin/htpasswd</code>
 195     にプログラムが置かれています。</p>
 196
 197     <p>次に、サーバがパスワードを要求するように設定して、
 198     どのユーザがアクセスを許されているかをサーバに知らせなければ
 199     なりません。 <code>httpd.conf</code> を編集するか
 200     <code>.htaccess</code> ファイルを使用するかで
 201     設定します。例えば、ディレクトリ
 202     <code>/usr/local/apache/htdocs/secret</code>
 203     を保護したい場合は、
 204     <code>/usr/local/apache/htdocs/secret/.htaccess</code>
 205     か httpd.conf 中の &lt;Directory
 206     /usr/local/apache/htdocs/secret&gt; セクションに
 207     配置して、次のディレクティブを使うことができます。</p>
 208
 209     <example>
 210       AuthType Basic<br />
 211       AuthName "Restricted Files"<br />
 212       # (Following line optional)<br />
 213       AuthBasicProvider file<br />
 214       AuthUserFile /usr/local/apache/passwd/passwords<br />
 215       Require user rbowen
 216     </example>
 217
 218     <p>個々のディレクティブについて見てみましょう。
 219     <directive module="core">AuthType</directive>
 220     ディレクティブはどういう認証方法でユーザの認証を行うかを
 221     選択します。最も一般的な方法は <code>Basic</code>
 222     で、これは <module>mod_auth_basic</module>
 223     で実装されています。しかしながら、
 224     これは気を付けるべき重要なポイントなのですが、
 225     Basic 認証はクライアントからサーバへ、
 226     パスワードを暗号化せずに送ります。ですからこの方法は、
 227     <module>mod_ssl</module> と組み合わせない状態では、
 228     特に機密性の高いデータに対しては用いるべきでは
 229     ありません。 Apache ではもう一つ別の認証方法:
 230     <code>AuthType Digest</code> をサポートしています。
 231     この方法は <module>mod_auth_digest</module>
 232     で実装されていて、もっと安全です。
 233     最近のクライアントは Digest
 234     認証をサポートしているようです。</p>
 235
 236     <p><directive module="core">AuthName</directive>
 237     ディレクティブでは、認証に使う <dfn>Realm</dfn> (訳注: 領域)
 238     を設定します。Realm は大きく分けて二つの機能を提供します。
 239     一つ目は、クライアントがパスワードダイアログボックスの
 240     一部としてユーザにこの情報をよく提示する、というものです。
 241     二つ目には、クライアントが与えられた認証領域に対してどのパスワードを
 242     送信すれば良いのかを決定するために使われる、という機能です。</p>
 243
 244     <p>例えば、<code>"Restricted Files"</code> 領域中で
 245     一度認証されれば、同一サーバ上で <code>"Restricted Files"</code>
 246     Realm としてマークされたどんな領域でも、クライアントは
 247     自動的に同じパスワードを使おうと試みます。
 248     このおかげで、複数の制限領域に同じ realm を共有させて、
 249     ユーザがパスワードを何度も要求される事態を
 250     防ぐことができます。もちろん、セキュリティ上の理由から、
 251     サーバのホスト名が変わればいつでも必ず、
 252     クライアントは再びパスワードを尋ねる必要があります。</p>
 253
 254     <p><directive
 255     module="mod_auth_basic">AuthBasicProvider</directive>
 256     はデフォルト値が <code>file</code> なので、今回の場合は無くても構いません。
 257     <module>mod_authn_dbm</module> や <module>mod_authn_dbd</module>
 258     といった他のモジュールを使う場合には必要になります。
 259     </p>
 260
 261     <p><directive module="mod_authn_file">AuthUserFile</directive>
 262     ディレクティブは <program>htpasswd</program> で作った
 263     パスワードファイルへのパスを設定します。
 264     ユーザ数が多い場合は、リクエスト毎のユーザの認証のための
 265     プレーンテキストの探索が非常に遅くなることがあります。
 266     Apache ではユーザ情報を高速なデータベースファイルに
 267     保管することもできます。
 268     <module>mod_authn_dbm</module> モジュールが
 269     <directive module="mod_authn_dbm">AuthDBMUserFile</directive>
 270     ディレクティブを提供します。これらのファイルは <program >dbmmanage</program>
 271     プログラムで作成したり操作したりできます。
 272     <a href="http://modules.apache.org/">Apache
 273     モジュールデータベース</a>中にあるサードパーティー製の
 274     モジュールで、その他多くのタイプの認証オプションが
 275     利用可能です。</p>
 276
 277     <p>最後に、<directive module="core">Require</directive>
 278     ディレクティブが、サーバのこの領域にアクセスできるユーザを
 279     指定することによって、プロセスの承認部分を提供します。
 280     次のセクションでは、<directive module="core">Require</directive>
 281     ディレクティブの様々な用法について述べます。</p>
 282 </section>
 283
 284 <section id="lettingmorethanonepersonin"><title>
 285 複数の人が入れるようにする</title>
 286     <p>上記のディレクティブは、ただ一人 (具体的にはユーザ名
 287     <code>rbowen</code> の誰か) がディレクトリに
 288     入れるようにします。多くの場合は、複数の人が
 289     入れるようにしたいでしょう。ここで
 290     <directive module="mod_authz_groupfile">AuthGroupFile</directive>
 291     の登場です。</p>
 292
 293     <p>もし複数の人が入れるようにしたいのであれば、
 294     グループに属するユーザの一覧の入っている、グループ名のついた
 295     グループファイルを作る必要があります。このファイルの
 296     書式はきわめて単純で、お好みのエディタで生成できます。
 297     ファイルの中身は次のようなものです。</p>
 298
 299    <example>
 300      GroupName: rbowen dpitts sungo rshersey
 301    </example>
 302
 303     <p>一行にスペース区切りで、グループに所属するメンバーの
 304     一覧をならべるだけです。</p>
 305
 306     <p>既に存在するパスワードファイルにユーザを加える場合は、
 307     次のようにタイプしてください。</p>
 308
 309     <example>
 310       htpasswd /usr/local/apache/passwd/passwords dpitts
 311     </example>
 312
 313     <p>以前と同じ応答が返されますが、新しいファイルを
 314     作るのではなく、既にあるファイルに追加されています。
 315     (新しいパスワードファイルを作るには <code>-c</code>
 316     を使います。)</p>
 317
 318     <p>ここで次のようにして <code>.htaccess</code> ファイルを
 319     修正する必要があります。</p>
 320
 321     <example>
 322       AuthType Basic<br />
 323       AuthName "By Invitation Only"<br />
 324       # Optional line:<br />
 325       AuthBasicProvider file<br />
 326       AuthUserFile /usr/local/apache/passwd/passwords<br />
 327       AuthGroupFile /usr/local/apache/passwd/groups<br />
 328       Require group GroupName
 329     </example>
 330
 331     <p>これで、グループ <code>GroupName</code> にリストされていて、
 332     <code>password</code> ファイルにエントリがある人は、
 333     正しいパスワードをタイプすれば入ることができるでしょう。</p>
 334
 335     <p>もっと特定せずに複数のユーザが入れるようにする、
 336     もう一つの方法があります。グループファイルを作るのではなく、
 337     次のディレクティブを使えばできます。</p>
 338
 339     <example>
 340       Require valid-user
 341     </example>
 342
 343     <p><code>require user rbowen</code> 行でなく、上記を使うと、
 344     パスワードファイルにリストされている人であれば誰でも
 345     許可されます。
 346     単にパスワードファイルをグループ毎に分けておくことで、
 347     グループのような振る舞いをさせることもできます。
 348     このアプローチの利点は、Apache は二つではなく、
 349     ただ一つのファイルだけを検査すればよいという点です。
 350     欠点は、たくさんのパスワードファイルを管理して、その中から
 351     <directive module="mod_authn_file">AuthUserFile</directive>
 352     ディレクティブに正しいファイルを参照させなければならない点です。</p>
 353 </section>
 354
 355 <section id="possibleproblems"><title>起こりえる問題</title>
 356     <p>Basic 認証が指定されている場合は、
 357     サーバにドキュメントをリクエストする度に
 358     ユーザ名とパスワードを検査しなければなりません。
 359     これは同じページ、ページにある全ての画像を
 360     リロードする場合であっても該当します
 361      (もし画像も保護されたディレクトリから来るのであれば) 。
 362     予想される通り、これは動作を多少遅くします。
 363     遅くなる程度はパスワードファイルの大きさと比例しますが、
 364     これは、ファイルを開いてあなたの名前を発見するまで
 365     ユーザ名のリストを読まなければならないからです。
 366     そして、ページがロードされる度にこれを行わなければ
 367     なりません。</p>
 368
 369     <p>結論としては、一つのパスワードファイルに置くことのできる
 370     ユーザ数には実質的な限界があります。
 371     この限界はサーバマシンの性能に依存して変わりますが、
 372     数百のエントリを越えたあたりから速度低下が見られると予期されています。
 373     その時は他の認証方法を考慮に入れた方が良いでしょう。</p>
 374 </section>
 375
 376 <section id="dbmdbd"><title>パスワードの保存形式を変える</title>
 377
 378     <p>プレーンテキストでパスワードを保存する方法には上記の問題があり、
 379     データベースのような別の場所にパスワードを保存したいと思う
 380     かもしれません。</p>
 381
 382     <p><module>mod_authn_dbm</module> と <module>mod_authn_dbd</module>
 383     を使うと、それができるようになります。
 384     <directive module="mod_auth_basic">AuthBasicSource</directive>
 385     で file の代わりに、<code>dbm</code> あるいは <code>dbd</code>
 386     を格納形式として選べます。</p>
 387
 388     <p>テキストファイルの代わりに dbm ファイルを選択する場合は、たとえば次のようにします。</p>
 389
 390     <example>
 391     &lt;Directory /www/docs/private&gt;<br />
 392     AuthName "Private"<br />
 393     AuthType Basic<br />
 394     AuthBasicProvider dbm<br />
 395     AuthDBMUserFile /www/passwords/passwd.dbm<br />
 396     Require valid-user<br />
 397     &lt;/Directory&gt;
 398     </example>
 399
 400     <p>この他のオプションも存在します。詳細に関しては
 401     <module>mod_authn_dbm</module> のドキュメントをご覧ください。</p>
 402 </section>
 403
 404 <section id="multprovider"><title>複数のプロバイダを使用する</title>
 405
 406     <p>認証承認アーキテクチャに基づいている新しいプロバイダを使うと、
 407     認証承認の方法をひとつに縛る必要がなくなります。
 408     いくつものプロバイダを組み合わせて、自分の望みの挙動にできます。
 409     次の例では file 認証プロバイダと ldap 認証プロバイダを
 410     組み合わせています。</p>
 411
 412     <example>
 413     &lt;Directory /www/docs/private&gt;<br />
 414     AuthName "Private"<br />
 415     AuthType Basic<br />
 416     AuthBasicProvider file ldap<br />
 417     AuthUserFile /usr/local/apache/passwd/passwords<br />
 418     AuthLDAPURL ldap://ldaphost/o=yourorg<br />
 419     Require valid-user
 420     </example>
 421
 422     <p>この例では、まず file プロバイダがユーザ認証を試みます。
 423     認証できなかった場合には、ldap プロバイダが呼び出されます。
 424     組織で複数の認証格納方法を使っている際などに、
 425     この方法を使って認証のスコープを拡大できます。
 426     もうひとつのシナリオは、ひとつの認証タイプと異なる承認を
 427     組み合わせる方法でしょう。たとえば、パスワードファイルで認証して、
 428     ldap ディレクトリで承認を行うといった場合です。</p>
 429
 430     <p>認証プロバイダを複数実装できるように、承認方法も複数使用できます。
 431     この例では file グループ承認と ldap グループ承認を使っています。</p>
 432
 433     <example>
 434     &lt;Directory /www/docs/private&gt;<br />
 435     AuthName "Private"<br />
 436     AuthType Basic<br />
 437     AuthBasicProvider file<br />
 438     AuthUserFile /usr/local/apache/passwd/passwords<br />
 439     AuthLDAPURL ldap://ldaphost/o=yourorg
 440     AuthGroupFile /usr/local/apache/passwd/groups<br />
 441     Require group GroupName<br />
 442     Require ldap-group cn=mygroup,o=yourorg
 443     </example>
 444
 445     <p>承認をより細かく制御したい場合は、
 446     <directive module="mod_authz_core">&lt;SatisfyAll&gt;</directive> と
 447     <directive module="mod_authz_core">&lt;SatisfyOne&gt;</directive>
 448     ディレクティブを使って AND/OR ロジックで指定し、設定ファイルで
 449     承認の処理順番の制御ができるようになっています。
 450     これらのディレクティブをどのように使えるか、網羅した例をご覧ください。</p>
 451
 452 </section>
 453
 454 <section id="beyond"><title>単純な承認のその先</title>
 455
 456     <p>承認の方法は、ひとつのデータソースを見て一回だけチェックするのと比べて、
 457     ずっと多彩な適用方法ができます。
 458     承認処理の適用順序や制御、選択ができるようになりました。</p>
 459
 460     <section id="authandororder"><title>AND/OR ロジックの適用と順序付け</title>
 461         <p>承認がどのような順序で適用されているか、また、それをどのように制御するかは、
 462         これまで混乱を招いていました。
 463         Apache 2.2 ではプロバイダベースの認証メカニズムが導入され、
 464         承認処理から認証処理とサポート機能とが切り分けられました。
 465         これによるひとつの効果として、
 466         認証モジュールのロード順やモジュール自体の順序に依存することなく、
 467         指定した順番で認証プロバイダが呼び出せるよう、
 468         設定できるようになりました。
 469         このプロバイダメカニズムは承認処理でも導入されています。
 470         つまり、<directive module="mod_authz_core">Require</directive>
 471         ディレクティブは単にどの承認手法が使われるかを指定するだけではなく、
 472         それらの呼び出し順序も指定できるようになりました。
 473         複数の承認手法があるとき、その呼び出し順は、設定ファイルの
 474         <directive module="mod_authz_core">Require</directive> ディレクティブ中で
 475         現れた順序と同じになります。</p>
 476
 477         <p>追加で導入された
 478         <directive module="mod_authz_core">&lt;SatisfyAll&gt;</directive>,
 479         <directive module="mod_authz_core">&lt;SatisfyOne&gt;</directive>
 480         ディレクティブを使って、承認手法がいつ呼び出され、アクセスが許可された際に
 481         どの手続きが適用されるか指定することができます。
 482         たとえば、次の承認ブロックのロジックを見てみましょう:</p>
 483
 484         <example>
 485           # if ((user == "John") ||<br />
 486           # &nbsp;&nbsp; ((Group == "admin")<br />
 487           # &nbsp; &nbsp; &amp;&amp; (ldap-group &lt;ldap-object&gt; contains auth'ed_user)<br />
 488           # &nbsp; &nbsp; &amp;&amp; ((ldap-attribute dept == "sales")<br />
 489           # &nbsp; &nbsp; &nbsp; &nbsp; || (file-group contains auth'ed_user))))<br />
 490           # then<br />
 491           # &nbsp; auth_granted<br />
 492           # else<br />
 493           # &nbsp; auth_denied<br />
 494           #<br />
 495           &lt;Directory /www/mydocs&gt;<br />
 496           <indent>
 497             Authname ...<br />
 498             AuthBasicProvider ...<br />
 499             ...<br />
 500             Require user John<br />
 501             &lt;SatisfyAll&gt;<br />
 502             <indent>
 503               Require Group admins<br />
 504               Require ldap-group cn=mygroup,o=foo<br />
 505               &lt;SatisfyOne&gt;<br />
 506               <indent>
 507                 Require ldap-attribute dept="sales"<br />
 508                 Require file-group<br />
 509               </indent>
 510               &lt;/SatisfyOne&gt;<br />
 511             </indent>
 512             &lt;/SatisfyAll&gt;<br />
 513           </indent>
 514           &lt;/Directory&gt;
 515         </example>
 516
 517         <p>デフォルトでは <directive module="mod_authz_core">Require</directive>
 518         ディレクティブは OR 操作として扱われます。つまり、もし指定した承認手法の
 519         ひとつでも合格すれば、承認されます。
 520         <directive module="mod_authz_core">Require</directive> ディレクティブのセットを
 521         ひとつの <directive module="mod_authz_core">&lt;SatisfyAll&gt;</directive>
 522         ブロックで囲むとAND 操作となり、全ての承認手法で合格しなければ許可されません。</p>
 523
 524     </section>
 525
 526     <section id="reqaccessctrl"><title>アクセス制御における Require と Reject の使い方</title>
 527         <p>ユーザ名とパスワードによる認証は全体の一部分でしかありません。
 528         誰がアクセスしてきたかといった情報以外の条件を使いたい、
 529         とよく思うことでしょう。
 530         たとえば、どこからアクセスしてきているか、といった具合です。</p>
 531
 532         <p>承認プロバイダ <directive module="mod_authz_host">all</directive>,
 533         <directive module="mod_authz_host">env</directive>,
 534         <directive module="mod_authz_host">host</directive>,
 535         <directive module="mod_authz_host">ip</directive>
 536         を使うと、リクエストを送信してきているマシンのホスト名や IP アドレス
 537         といった、ホストベースでのアクセス制御ができます。</p>
 538
 539         <p>これらプロバイダの扱いは
 540         <directive module="mod_authz_core">Require</directive> や
 541         <directive module="mod_authz_core">Reject</directive> で
 542         指定されます。これらのディレクティブは承認プロバイダを登録し、
 543         リクエスト処理の承認段階で呼び出されます。たとえば:</p>
 544
 545         <example>
 546           Require ip <var>address</var>
 547         </example>
 548
 549         <p>ここで、<var>address</var> は IP アドレス (あるいは IP アドレスの
 550         一部) か : </p>
 551
 552         <example>
 553           Require host <var>domain_name</var>
 554         </example>
 555
 556         <p>ここで <var>domain_name</var> は FQDN (あるいはドメイン名の一部)
 557         で、必要であれば複数のアドレスやドメイン名を書くことができます。</p>
 558
 559         <p>たとえば、スパムメッセージを送信してくる誰かを拒否したい場合、
 560         次のようになります : </p>
 561
 562         <example>
 563           Reject ip 10.252.46.165
 564         </example>
 565
 566         <p>このディレクティブが有効な範囲のコンテンツに対しては、
 567         そのアドレスからアクセスしてきても見ることができません。
 568         もしマシン名がわかっていて IP アドレスよりもそちらで
 569         指定したいのであれば、そのマシン名が使えます。</p>
 570
 571         <example>
 572           Reject host <var>host.example.com</var>
 573         </example>
 574
 575         <p>また、特定のドメインからのアクセス全てをブロックしたい場合は、
 576         IP アドレスの一部や、ドメイン名が指定できます :</p>
 577
 578         <example>
 579           &lt;SatisfyAll&gt;<br />
 580           <indent>
 581             Reject ip <var>192.168.205</var><br />
 582             Reject host <var>phishers.example.com</var> <var>moreidiots.example</var><br />           Reject host ke<br />
 583           </indent>
 584           &lt;/SatisfyAll&gt;
 585         </example>
 586
 587         <p><directive module="mod_authz_host">Reject</directive> ディレクティブを
 588         <directive module="mod_authz_core">&lt;SatisfyAll&gt;</directive> ブロックの中で使うと、
 589         許可したいグループにのみアクセスができるように確認できます。</p>
 590
 591         <p>上記の例では <directive module="mod_authz_core">&lt;SatisfyAll&gt;</directive>
 592         を使って、アクセスに合格する前段階で、全ての
 593         <directive module="mod_authz_host">Reject</directive> ディレクティブが
 594         満たされていることを確認しています。</p>
 595
 596     </section>
 597
 598     <section id="filesystem"><title>アクセス制御の後方互換性</title>
 599         <p>認証プロバイダベースの機構があるため、以前使用されていたディレクティブ
 600         <directive module="mod_access_compat">Order</directive>,
 601         <directive module="mod_access_compat">Allow</directive>,
 602         <directive module="mod_access_compat">Deny</directive>,
 603         <directive module="mod_access_compat">Satisfy</directive>
 604         は必要なくなりました。
 605         とはいうものの、古い設定ファイルでの後方互換性を提供するため、
 606         これらのディレクティブは <module>mod_access_compat</module> モジュールに移されました。</p>
 607
 608         <p>これらのディレクティブの抱えていた問題のひとつに、承認の設定行とアクセス制御の設定行の
 609         関係がとてもあいまいだったことが挙げられます。
 610         <directive module="mod_access_compat">Satisfy</directive> ディレクティブは
 611         リクエスト処理中でそれ自身を呼び出すことによって、これらの 2 つの処理段階を結びつけようとします。
 612         現在は、これらのディレクティブは <module>mod_access_compat</module> に移動し、
 613         新しい認証ディレクティブと古いアクセス制御ディレクティブを混ぜて使うことは
 614         難しくなっています。この問題のため、<module>mod_authz_default</module> モジュールを
 615         ロードすることがとても重要で、必須になっています。
 616         <module>mod_authz_default</module>　モジュールの主な目的は、どの承認プロバイダで
 617         処理されなかった承認リクエストを受けることにあります。
 618         しかし、古いアクセス制御ディレクティブが用いられた場合には、
 619         アクセス制御と承認を結びつけて、すべての処理段階の出力結果を見てアクセスに合格するかを決めています。
 620         ですから、古いディレクティブがうまく動作しない場合は、
 621         <module>mod_authz_default</module> がロードされていないからかもしれない、
 622         と疑ってみてください。</p>
 623
 624     </section>
 625
 626 </section>
 627
 628 <section id="moreinformation"><title>追加情報</title>
 629     <p>これら全てがどのように動作するかについて
 630     もっと多くの情報が書かれている <module>mod_auth_basic</module> と
 631     <module>mod_authz_host</module>
 632     の文書も読むとよいでしょう。
 633     <directive module="mod_authn_core">&lt;AuthnProviderAlias&gt;</directive>
 634     ディレクティブを使うと、特定の認証設定が簡単に書けるようになります。</p>
 635
 636     <p><a href="access.html">アクセス制御</a>の方法も、
 637     関連するトピックがたくさん記載されていますので、ご覧ください。</p>
 638
 639 </section>
 640
 641 </manualpage>
 642