Sun Java System Web Proxy Server 4.0.1 管理ガイド |
第 8 章
サーバーへのアクセス制御この章では、管理サーバーおよび Proxy Server によって処理されるデータへのアクセス制御の方法について説明します。サーバーにより処理されるすべてのデータ、またはサーバーがサービスを提供する特定の URL のアクセスを制限できます。たとえば、特定の URL へのアクセスを特定のユーザーに限定したり、特定のユーザー以外のすべてのユーザーがファイルを表示できるように指定できます。すべてのクライアントに HTTP の URL へのアクセスを許可し、FTP へは限定されたアクセスのみを許可することもできます。また、複数の内部 Web サーバーにサービスを提供している Proxy Server があり、それらのサーバーのいずれかに格納された極秘調査プロジェクトへは特定のユーザーのみがアクセスできるようにしたい場合などに、ホスト名またはドメイン名に基づいて URL を制限することもできます。
管理サーバーでアクセス制御を使用するには、分散管理を有効にして、LDAP データベースに管理グループを設定する必要があります。この章の内容は、それらの作業が済んでいることを前提としています。
この章では、次の項目について説明します。
アクセス制御とはアクセス制御により、Proxy Server にアクセスできるユーザー、およびアクセス可能なサーバーの部分を指定することができます。サーバーへのアクセスの制御は、サーバー全体に対して、またはディレクトリ、ファイル、ファイルタイプなどのサーバーの一部に対して行うことができます。受信した要求が評価される場合、アクセス制御エントリ (Access Control Entry、ACE) と呼ばれる規則の階層に基づいてアクセスが決定されます。Proxy Server は一致するエントリを検索して、アクセスを許可するか、拒否するかを決定します。各 ACE は、サーバーが階層内の次のエントリに進むべきかどうかを指定します。ACE の集合は、アクセス制御リスト (ACL) と呼ばれます。要求を受信すると、obj.conf ファイルでアクセスの決定に使用される ACL の参照がチェックされます。デフォルトでは、サーバーには複数の ACL が含まれる 1 つの ACL ファイルがあります。
アクセスは次の内容に基づいて許可または拒否されます。
この節では、次の内容について説明します。
ユーザー - グループのアクセス制御
特定のユーザーまたはグループに対して、サーバーへのアクセスを制限することができます。ユーザー - グループのアクセス制御を設定した場合、サーバーにアクセスする前に、ユーザーはユーザー名とパスワードの入力を求められます。サーバーは、クライアント証明書の情報、またはクライアント証明書自体を、ディレクトリサーバーのエントリと比較します。
管理サーバーでは、基本認証だけを使用します。管理サーバーでクライアント認証を要求する場合、obj.conf の ACL ファイルを手動で編集し、認証方法を SSL に変更する必要があります。
ユーザーグループ認証は、サーバーに設定されているディレクトリサービスによって実行されます。詳細は、「ディレクトリサービスの設定」を参照してください。
ディレクトリサービスがアクセス制御の実装に使用する情報は、次のソースのいずれかから入手できます。
サーバーは、外部 LDAP ベースのディレクトリサービスを使用するとき、サーバーインスタンスに対して次のタイプのユーザーグループ認証方法をサポートします。
サーバーが内部ファイルベースのディレクトリサービスを使用するときに、サーバーインスタンスに対してサポートされるユーザー - グループ認証方法には、次のものがあります。
ユーザー - グループ認証を設定した場合、ユーザーはアクセスする前に、ユーザー自身の認証を求められます。認証の際、ユーザーはユーザー名とパスワードの入力、クライアント証明書の使用、またはダイジェスト認証プラグインを使用することによってユーザー自身の識別情報を証明します。クライアント証明書を使用する場合、暗号化が必要になります。
デフォルト認証
デフォルト認証は、推奨される方法です。デフォルト設定では、obj.conf ファイルで指定したデフォルトの方法を使用します。obj.conf で方法が設定されていない場合は、「Basic」を使用します。「Default」を選択した場合、ACL 規則によって ACL ファイル内の方法が指定されることはありません。「Default」を選択すると、obj.conf ファイル内の 1 行を編集することによって、すべての ACL の方法を簡単に変更できます。
基本認証
基本認証を選択した場合、サーバーにアクセスするためにユーザーはユーザー名とパスワードの入力を求められます。これがデフォルトの設定です。Sun Java System Directory Server などの LDAP データベース、またはファイルにユーザーとグループのリストを作成して格納する必要があります。Proxy Server とは別のサーバールートにインストールされたディレクトリサーバー、またはリモートコンピュータにインストールされたディレクトリサーバーを使用する必要があります。
ユーザーがユーザー - グループ認証を行うリソースへアクセスしようとすると、ユーザー名とパスワードの入力を求められます。サーバーで暗号化が設定されている (SSL が有効) かどうかに応じて、サーバーはこの情報を暗号化された状態、または暗号化されていない状態で受信します。
認証の後、ユーザーには次の内容が表示されます。
承認されていないユーザーから受信するメッセージはカスタマイズできます。詳細は、「アクセスが拒否された場合の応答」を参照してください。
SSL 認証
サーバーは、次の 2 つの方法で、セキュリティ証明書付きのユーザーの識別情報を確認できます。
クライアントの認証で証明書の情報を使用するようにサーバーを設定した場合、サーバーは次の処理を実行します。
- 信頼できる CA (証明書発行局) から発行された証明書かどうかを確認します。そうでない場合、認証は失敗し、トランザクションが終了します。クライアント証明書を有効にする方法については、「セキュリティーに関する詳細設定」を参照してください。
- 証明書が信頼できる CA から発行されたものである場合は、certmap.conf ファイルを使用して、証明書をユーザーのエントリにマップします。証明書マッピングファイルの設定方法については、「certmap.conf ファイルの使用」を参照してください。
- 証明書が正しくマップされている場合は、そのユーザーに対して指定されている ACL 規則を確認します。証明書が正しくマップされている場合でも、ACL 規則によってユーザーのアクセスが拒否される可能性もあります。
特定のリソースへのアクセスを制御するためにクライアント認証を要求することは、サーバーへの接続のすべてに対してクライアント認証を要求することとは異なります。すべての接続に対してクライアント認証を要求するようにサーバーを設定した場合、クライアントは信頼できる CA によって発行された有効な証明書のみを提示する必要があります。ユーザーとグループの認証に SSL メソッドを使用するようにサーバーを設定した場合、次のことが行われます。
アクセス制御を使用してクライアント認証を要求する場合、Proxy Server で SSL 暗号化方式を有効にする必要があります。SSL の有効化については、「証明書と鍵の使用」を参照してください。
SSL で認証されるリソースにアクセスするには、Proxy Server により信頼できる CA から、クライアント証明書が発行されている必要があります。ブラウザのクライアント証明書とディレクトリサーバーのクライアント証明書を比較するように Proxy Server の certmap.conf ファイルが設定されている場合、クライアント証明書はディレクトリサーバーで発行されている必要があります。ただし、証明書から選択した情報とディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することもできます。たとえば、ブラウザ証明書のユーザー ID および電子メールアドレスとディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することができます。certmap.conf と証明書マッピングについては、「証明書と鍵の使用」を参照してください。『Proxy Server Configuration File Reference』も参照してください。
ダイジェスト認証
Proxy Server は、LDAP ベースまたはファイルベースのいずれかのディレクトリサービスを使用して、ダイジェスト認証を行うように設定できます。
ダイジェスト認証では、ユーザーがユーザー名とパスワードをクリアテキストとして送信することなく、ユーザー名とパスワードに基づいた認証を行うことができます。ブラウザは MD5 アルゴリズムを使用して、ユーザーのパスワードと Proxy Server によって提供される情報の一部を使用するダイジェスト値を作成します。
サーバーが LDAP ベースのディレクトリサービスを使用してダイジェスト認証を行うとき、このダイジェスト値は、ダイジェスト認証プラグインを使用してサーバー側で計算され、クライアントによって提示されたダイジェスト値と比較されます。ダイジェスト値が一致した場合、ユーザーは認証されます。これが機能するには、ディレクトリサーバーがクリアテキスト形式のユーザーのパスワードにアクセスできる必要があります。Sun Java System Directory Server にはリバーシブルパスワードプラグインが組み込まれています。このプラグインは、対称暗号化アルゴリズムを使用し、暗号化された形式にしてデータを格納し、あとで元の形式に復号化することができます。データへの鍵を持っているのは Directory Server だけです。
LDAP ベースのダイジェスト認証の場合、リバーシブルパスワードプラグインと、Proxy Server に組み込まれているダイジェスト認証専用のプラグインを有効にする必要があります。ダイジェスト認証を処理するように Proxy Server を設定するには、server_root/userdb/ 内の dbswitch.conf ファイルで、データベース定義の digestauth プロパティを設定します。
サーバーは、指定されている ACL 方式に基づいて、LDAP データベースに対して認証を試みます。表 8-1 を参照してください。ACL 方式を指定しない場合、認証が必要であればダイジェスト認証または基本認証のいずれかが使用され、認証が必要ない場合は基本認証が使用されます。
次の表は、認証データベースでサポートされる、あるいはサポートされないダイジェスト認証を示しています。
表 8-1 ダイジェスト認証要求の生成
ACL 方式
認証データベースでサポートされる方式
認証データベースでサポートされない方式
デフォルト
指定なし
ダイジェストと基本
基本
基本
基本
基本
ダイジェスト
ダイジェスト
エラー
method = digest を指定して ACL を処理する場合、サーバーは次のことを実行して認証を試みます。
- 認証要求のヘッダーを確認します。見つからない場合は、ダイジェスト要求に対して 401 の応答が生成され、プロセスが停止します。
- 認証のタイプを確認します。認証のタイプがダイジェストの場合、サーバーは次のことを実行します。
- レルムを確認します。一致するものが見つからない場合は、401 の応答が生成されてプロセスが停止します。
- 認証ディレクトリが LDAP ベースの場合は LDAP ディレクトリにユーザーが存在するかどうかを確認します。認証ディレクトリがファイルベースの場合はファイルデータベースにユーザーが存在するかどうかを確認します。見つからない場合は、401 の応答が生成されてプロセスが停止します。
- ディレクトリサーバーまたはファイルデータベースから request-digest 値を取得し、クライアントの request-digest 値と一致することを確認します。一致するものが見つからない場合は、401 の応答が生成されてプロセスが停止します。
- Authorization-Info ヘッダーを構築し、サーバーヘッダーに挿入します。
ダイジェスト認証プラグインのインストール
LDAP ベースのディレクトリサービスを使用するダイジェスト認証の場合、ダイジェスト認証プラグインをインストールする必要があります。このプラグインは、サーバー側でダイジェスト値を計算し、この値をクライアントによって提供されるダイジェスト値と比較します。ダイジェスト値が一致した場合、ユーザーは認証されます。
ファイルベースの認証データベースを使用する場合、ダイジェスト認証プラグインをインストールする必要はありません。
UNIX でのダイジェスト認証プラグインのインストール
ダイジェスト認証プラグインは、次の両方に存在する共用ライブラリで構成されています。
UNIX でダイジェスト認証プラグインをインストールするには
- この共用ライブラリが、Sun Java System Directory Server がインストールされているのと同じサーバーコンピュータにあることを確認します。
- ディレクトリマネージャーのパスワードを確認します。
- /path/to へのすべての参照が、ダイジェストプラグインの共用ライブラリのインストール先に変更されるように、libdigest-plugin.ldif ファイルを修正します。
- プラグインをインストールするには、次のコマンドを入力します。
% ldapmodify -D "cn=Directory Manager" -w password -a < libdigest-plugin.ldif
Windows でのダイジェスト認証プラグインのインストール
ダイジェストプラグインとともに Sun Java System Directory Server コンピュータが正しく起動できるようにするには、Proxy Server のいくつかの .dll ファイルを Directory Server コンピュータにコピーする必要があります。
Windows でダイジェスト認証プラグインをインストールするには
DES アルゴリズムを使用するための Sun Java System Directory Server の設定
DES アルゴリズムは、ダイジェストパスワードが格納されている属性を暗号化するために必要です。
DES アルゴリズムを使用するように Directory Server を設定するには
その他の認証
アクセス制御 API を使用すると、カスタムの認証方法を作成できます。
ホスト - IP のアクセス制御
管理サーバーおよびそのファイルとディレクトリに対して、特定のコンピュータを使用しているクライアントだけが利用できるように、アクセスを制限できます。そのためには、アクセスの許可または拒否を行うコンピュータのホスト名または IP アドレスを指定します。ホスト - IP 認証を使用したファイルまたはディレクトリへのアクセスは、ユーザーにはシームレスに見えます。このため、ユーザーは、ユーザー名やパスワードを入力することなく、すぐにファイルやディレクトリにアクセスできます。
特定のコンピュータを複数のユーザーが使用していることもあるため、ホスト - IP 認証は、ユーザー - グループ認証と組み合わせるとより効果的です。両方の認証方法を使用する場合は、アクセスするときにユーザー名とパスワードを求められます。
ホスト - IP 認証では、サーバーで DNS (ドメインネームサービス) を設定する必要はありません。、ホスト - IP 認証を使用する場合は、ネットワークで DNS が稼働しており、この認証を使用するようにサーバーが設定されている必要があります。DNS を有効にするには、サーバーのサーバーマネージャーにアクセスし、「Preferences」タブをクリックし、「Configure System Preferences」をクリックします。DNS の設定が表示されます。
DNS を有効にすると、サーバーで DNS 検索が強制的に実行されるため、Proxy Server のパフォーマンスが低下します。サーバーパフォーマンスへの DNS 検索の影響を小さくするには、すべての要求に対して IP アドレスを解決する代わりに、アクセス制御と CGI に対してだけ IP アドレスを解決します。このためには、obj.conf ファイルで次の内容を指定します。
AddLog fn="flex-log" name="access" iponly=1
アクセス制御ファイルの使用
管理サーバーまたはサーバー上のファイルやディレクトリに対してアクセス制御を使用する場合、拡張子が .acl のファイルに設定が格納されます。アクセス制御ファイルは server_root/httpacl ディレクトリに置かれます。server_root はサーバーがインストールされている場所です。たとえば、/usr/Sun/Servers にサーバーをインストールした場合、管理サーバーとサーバーに設定されている各サーバーインスタンスの両方の ACL ファイルが、/usr/Sun/Servers/httpacl/ に格納されます。
主要な ACL ファイルは generated-proxy-serverid.acl です。一時的な作業ファイルは genwork-proxy-serverid.acl です。管理サーバーを使用してアクセスを設定する場合は、これらの 2 つのファイルが作成されます。ただし、複雑な制約が必要な場合は、複数のファイルを作成し、server.xml ファイルから参照することができます。また、時刻や曜日を基準にしたサーバーへのアクセス制限など、ファイルを編集するだけで利用できる機能もいくつかあります。
アクセス制御ファイルとその構文については、「ACL ファイルの構文」を参照してください。server.xml については、『Proxy Server Configuration File Reference』を参照してください。
ACL ユーザーキャッシュの設定
デフォルトでは、Proxy Server によるユーザーとグループの認証の結果が、ACL ユーザーキャッシュに保存されます。magnus.conf ファイルの ACLCacheLifetime 指令を使用して、ACL ユーザーキャッシュを有効にする期間を制御することができます。キャッシュのエントリが参照されるたびにその経過時間が計算され、ACLCacheLifetime と照合されます。経過時間が ACLCacheLifetime と同じか、それよりも長い場合、このエントリは使用されません。デフォルト値は 120 秒です。値を 0 (ゼロ) に設定すると、キャッシュが無効になります。この値に大きな値を使用する場合、LDAP エントリを変更するたびに Proxy Server の起動が必要となる可能性があります。たとえば、この値を 120 秒に設定した場合は、Proxy Server と LDAP ディレクトリの同期が 2 分間にわたって取られない可能性があります。LDAP ディレクトリが頻繁に変更される可能性が低い場合にだけ、大きな値を設定します。
magnus.conf の ACLUserCacheSize パラメータを使用すると、キャッシュ内に保存できるエントリの最大数を設定できます。このパラメータのデフォルト値は 200 です。新しいエントリがリストの先頭に追加され、キャッシュが最大サイズに達すると、新しいエントリを作成するために、このリストの最後のエントリが再利用されます。
また、magnus.conf に含まれるパラメータである ACLGroupCacheSize を使用して、ユーザーエントリごとにキャッシュできるグループメンバーシップの最大数を設定することもできます。このパラメータのデフォルト値は 4 です。ただし、グループのメンバーではないユーザーはキャッシュされず、要求ごとに何回か LDAP ディレクトリにアクセスすることになります。
クライアント証明書によるアクセス制御
サーバー上で SSL が有効になっている場合、アクセス制御とともにクライアント証明書を使用できます。このためには、特定のリソースへのアクセスにクライアント証明書が必要であることを指定する必要があります。サーバーでこの機能を有効にした場合、証明書を持つユーザーは、制限されたリソースに初めてアクセスを試みる場合にのみ、名前とパスワードを入力します。ユーザーの識別情報がいったん確立されると、サーバーはログイン名とパスワードを個々の証明書にマップします。その後、ユーザーはクライアント認証の必要なリソースにアクセスする場合、ログイン名とパスワードを入力する必要がなくなります。ユーザーが制限されたリソースへのアクセスを試みた場合、ユーザーのクライアントはクライアント証明書をサーバーに送信し、サーバーはこれをマッピングリストと照合します。証明書がアクセス権を付与したユーザーのものである場合、リソースが提供されます。
アクセス制御のしくみサーバーはページの要求を受け取ると、ACL ファイル内の規則を使用して、アクセスを許可するか拒否するか判断します。規則は、要求を送信しているコンピュータのホスト名や IP アドレスを参照できます。また、規則が LDAP ディレクトリに格納されているユーザーやグループを参照するように設定することもできます。
次の例では、ACL ファイルのコンテンツと、アクセス制御規則を示しています。
たとえば、ユーザーが次の URL を要求した場合を考えてみます。http://server_name/my_stuff/web/presentation.html
Proxy Server は、まずサーバー全体のアクセス制御を確認します。サーバー全体への ACL で続行するように設定されている場合、サーバーは my_stuff ディレクトリの ACL を確認します。ACL が存在する場合、サーバーは ACL 内の ACE を確認し、次のディレクトリに移動します。このプロセスは、アクセスを拒否する ACL が見つかるまで、または要求された URL の最後の ACL (この場合は、ファイル presentation.html) に到達するまで続行されます。
サーバーマネージャーを使用してこの例のアクセス制御を設定するには、このファイルだけを対象とした ACL の作成のほか、ファイルへ誘導する各リソースの ACL を作成することができます。つまり、1 つはサーバー全体用、1 つは my_stuff ディレクトリ用、1 つは my_stuff/web ディレクトリ用、1 つはファイル用です。
アクセス制御の設定この節では、アクセスの制限プロセスについて説明します。すべてのサーバーに対してグローバルアクセス制御規則を設定することも、特定のサーバーに対して個別に設定することもできます。たとえば、人事部門では、認証されたすべてのユーザーに各自の給与データを見ることを許可し、データを更新するのは人事部門の給与担当者だけに制限する ACL を作成することもできます。
この節では、次の内容について説明します。
グローバルなアクセス制御の設定
すべてのサーバーにアクセス制御を設定するには
- 管理サーバーにアクセスして、「Global Settings」タブをクリックします。
- 「Administer Access Control」リンクをクリックします。
- ドロップダウンリストから管理サーバー (proxy-admserv) を選択し、「Go」をクリックしてデータをロードし、「New ACL」(または「Edit ACL」) をクリックします。
- プロンプトが表示されたら認証します。「Access Control Rules For」ページが表示されます。管理サーバーには、編集できないデフォルトアクセス制御規則が 2 行あります。
- チェックマークが付いていない場合は、「Access control Is On」チェックボックスにチェックマークを付けます。
- テーブルの最下行にデフォルトの ACL 規則を追加するには、「New Line」ボタンをクリックします。アクセス制御の制限位置を変更するには、上向きまたは下向き矢印をクリックします。
- 「Users/Groups」列の「Anyone」をクリックします。下のフレームに「Users/Groups」ページが表示されます。
- アクセスを許可するユーザーやグループを選択し、「Update」をクリックします。グループまたはユーザーの「List」ボタンをクリックすると、選択肢のリストが表示されます。設定については、オンラインヘルプを参照してください。「ユーザーとグループの指定」も参照してください。
- 「From Host」列の「Anyplace」をクリックします。下のフレームに「From Host」ページが表示されます。
- アクセスを許可するホスト名と IP アドレスを入力し、「Update」をクリックします。設定については、オンラインヘルプを参照してください。「「From Host」の指定」も参照してください。
- 「Programs」列の「All」をクリックします。下のフレームに「Programs」ページが表示されます。
- 「Program Groups」を選択するか、または「Program Items」フィールドにアクセスを許可する特定のファイル名を入力し、「Update」をクリックします。設定については、オンラインヘルプを参照してください。「プログラムへのアクセス制限」も参照してください。
- (オプション)「Add」列の「X」をクリックして、カスタマイズした ACL 式を追加します。下のフレームに「Customized Expressions」ページが表示されます。詳細は、「カスタマイズされた式の作成」を参照してください。
- 「継続」列のチェックボックスをまだ選択していない場合は、選択します。サーバーは次の行を評価してから、ユーザーがアクセスを許可されているかどうかを判断します。複数の行を作成する場合は、もっとも一般的な制限からより特殊な制限に移るようにしてください。
- (オプション) ごみ箱アイコンをクリックして、アクセス制御規則から対応する行を削除します。
- (オプション)「Response When Denied」リンクをクリックし、ユーザーがアクセスを拒否されたときに受け取る応答を指定します。下のフレームに「Access Deny Response」ページが表示されます。希望する応答を選択し、必要に応じて追加情報を指定し、「Update」をクリックします。設定については、「アクセスが拒否された場合の応答」を参照してください。
- 「Submit」をクリックして新しいアクセス制御規則を ACL ファイルに保存するか、「Revert」をクリックして、ページ内の要素を変更前の値にリセットします。
サーバーインスタンスに対するアクセス制御の設定
サーバーマネージャーを使用すると、特定のサーバーインスタンスに対するアクセス制御の作成、編集、または削除を実行できます。削除する場合、ACL ファイルからすべての ACL 規則を削除しないでください。サーバーを起動するには、少なくとも 1 つの ACL 規則が含まれる ACL ファイルが 1 つ以上必要です。すべての ACL 規則を削除してサーバーを再起動すると、構文エラーが発生します。
サーバーインスタンスにアクセス制御を設定するには
- サーバーマネージャーにアクセスしてサーバーインスタンスを選択し、「Preferences」タブをクリックします。
- 「Administer Access Control」リンクをクリックします。
- 次の方法のいずれかを使用して ACL を選択します。
- 「Select A Resource」: ACL を使用するリソースを表示して、アクセスを制限します。ドロップダウンリストからリソースを選択するか、「Regular Expression」をクリックして正規表現を指定します。詳細は、『Proxy Server 管理ガイド』の「テンプレートとリソースの管理」を参照してください。
- 「Select An Existing ACL」: 有効なすべての ACL を表示します。このリストには、有効になっていない既存の ACL は表示されません。ドロップダウンリストから選択します。
- 「Type In The ACL Name」: 名前付き ACL を作成します。このオプションは、ACL ファイルについてよく理解している場合にだけ使用してください。名前付き ACL をリソースに適用する場合は、obj.conf ファイルを手動で編集する必要があります。詳細は、「ACL ファイルの構文」を参照してください。
- 対応する「Edit」ボタンをクリックします。「Access Control Rules For」ページが表示されます。
- チェックマークが付いていない場合は、「Access control Is On」チェックボックスにチェックマークを付けます。
- テーブルの最下行にデフォルトの ACL 規則を追加するには、「New Line」ボタンをクリックします。アクセス制御の制限位置を変更するには、上向きまたは下向き矢印をクリックします。
- このサーバーインスタンス用の ACL を編集するには、「Action」列でアクションをクリックします。下のフレームに「Allow/Deny」ページが表示されます。
- デフォルトで選択されていない場合は「Allow」を選択し、「Update」をクリックします。「Allow」または「Deny」については、「アクションの設定」を参照してください。
- 「Users/Groups」列の「Anyone」をクリックします。下のフレームに「Users/Groups」ページが表示されます。
- アクセスを許可するユーザーやグループを選択し、認証情報を指定して、「Update」をクリックします。グループまたはユーザーの「List」ボタンをクリックすると、選択肢のリストが表示されます。設定については、オンラインヘルプを参照してください。「ユーザーとグループの指定」も参照してください。
- 「From Host」列の「Anyplace」をクリックします。下のフレームに「From Host」ページが表示されます。
- アクセスを許可するホスト名と IP アドレスを入力し、「Update」をクリックします。設定については、オンラインヘルプを参照してください。「「From Host」の指定」も参照してください。
- 「Rights」列の「All」をクリックします。下のフレームに「Access Rights」ページが表示されます。
- 該当ユーザーのアクセス権限を指定し、「Update」をクリックします。詳細は、「プログラムへのアクセス制限」を参照してください。
- (オプション)「Add」列の「X」をクリックして、カスタマイズした ACL 式を追加します。下のフレームに「Customized Expressions」ページが表示されます。詳細は、「カスタマイズされた式の作成」を参照してください。
- 「継続」列のチェックボックスをまだ選択していない場合は、選択します。サーバーは次の行を評価してから、ユーザーがアクセスを許可されているかどうかを判断します。複数の行を作成する場合は、もっとも一般的な制限からより特殊な制限に移るようにしてください。
- (オプション) ごみ箱アイコンをクリックして、アクセス制御規則から対応する行を削除します。ACL ファイルからすべての ACL 規則を削除しないでください。サーバーを起動するには、1 つ以上の ACL 規則が含まれる ACL ファイルが少なくとも 1 つ必要です。ACL ファイルのすべての ACL 規則を削除し、サーバーを再起動しようとすると、構文エラーになります。
- (オプション)「Response When Denied」リンクをクリックし、ユーザーがアクセスを拒否されたときに受け取る応答を指定します。下のフレームに「Access Deny Response」ページが表示されます。希望する応答を選択し、必要に応じて追加情報を指定し、「Update」をクリックします。設定については、「アクセスが拒否された場合の応答」を参照してください。
- 「Submit」をクリックして新しいアクセス制御規則を ACL ファイルに保存するか、「Revert」をクリックして、ページ内の要素を変更前の値にリセットします。
アクセス制御オプションの選択次のトピックでは、アクセス制御を設定するときに選択できる個々のオプションについて説明します。管理サーバーの場合は、最初の 2 行はデフォルトとして設定されていて、編集できません。
この節では、次の内容について説明します。
アクションの設定
要求がアクション制御規則と一致する場合にサーバーが実行するアクションを指定できます。
サーバーはアクセス制御エントリ (Access Control Entry、ACE) のリストを参照して、アクセス権を決定します。たとえば、最初の ACE は通常、すべてのユーザーを拒否します。最初の ACE に「継続」が設定されている場合、サーバーはリストの 2 番目の ACE を確認し、一致している場合は、次の ACE を使用します。「継続」チェックボックスが選択されていない場合は、すべてのユーザーがリソースへのアクセスを拒否されます。サーバーは、一致しない ACE か、一致しているが継続しない ACE のどちらかに到達するまでリストを参照し続けます。一致する最後の ACE によって、アクセスが許可されるか拒否されるかが決まります。
ユーザーとグループの指定
ユーザーとグループの認証が行われる場合、ユーザーがアクセス制御規則で指定されているリソースにアクセスするには、ユーザー名とパスワードを入力する必要があります。
Proxy Server は、Sun Java System Directory Server などの LDAP サーバー、または内部ファイルベースの認証データベースのいずれかに格納されているユーザーとグループのリストを確認します。
データベース内のすべてのユーザーに対してアクセスを許可または拒否することも、ワイルドカードパターンを使用して特定のユーザーに対してアクセスを許可または拒否することも、アクセスを許可または拒否する対象をユーザーとグループのリストから選択することもできます。
ユーザーインタフェースの「Access Control Rules For」ページにある「Users/Groups」には、次の要素が表示されます。
- 「Anyone (No Authentication)」はデフォルト値で、すべてのユーザーがユーザー名とパスワードを入力しなくても、リソースにアクセスできることを意味します。ただし、ホスト名や IP アドレスなど、その他の設定に基づいてユーザーのアクセスが拒否される場合もあります。管理サーバーの場合、このオプションは、分散管理のために指定した管理者グループ内のすべてのユーザーがページにアクセスできることを意味します。
- 「Authenticated People Only」
- 「All In The Authentication Database」は、データベースにエントリがあるユーザーに一致します。
- 「Only The following People」では、一致するユーザーとグループを指定します。エントリをコンマ (,) で区切るか、またはワイルドカードパターンを使用すると、ユーザーとユーザーグループの任意のリストを作成することができます。また、データベースに格納されているユーザーやグループのリストから選択することもできます。「Group」は、指定したグループ内のすべてのユーザーに一致します。「User」は、指定した個々のユーザーに一致します。管理サーバーでは、ユーザーを分散管理のために指定した管理者グループのメンバーにする必要があります。
- 「Prompt For Authentication」では、認証ダイアログボックスに表示されるメッセージテキストを入力します。このテキストを使用して、ユーザーが入力する必要のある項目について説明することができます。オペレーティングシステムによっては、最初の 40 文字程度しか表示されません。ほどんどのブラウザでは、ユーザー名とパスワードをキャッシュし、それらをプロンプトのテキストと関連付けます。これは、ユーザーが同じプロンプトが表示されるサーバーの領域 (ファイルやディレクトリ) にアクセスする場合、ユーザー名とパスワードを再入力する必要がないことを意味します。逆に、さまざまな領域でユーザーに対して再認証を求めるようにする場合、そのリソースに対する ACL のプロンプトを変更する必要があります。
- 「Authentication Methods」では、クライアントから認証情報を取得するためにサーバーが使用する方法を指定します。管理サーバーで使用できるのは、認証の基本メソッドだけです。サーバーマネージャーは、次のオプションを提供します。
- 「Default」では、obj.conf ファイルで指定されているデフォルトメソッドを使用します。obj.conf ファイルに設定されていない場合は「Basic」を使用します。「Default」を選択した場合、ACL 規則によって ACL ファイル内のメソッドが指定されることはありません。「Default」を選択すると、obj.conf ファイル内の 1 行を編集することによって、すべての ACL の方法を簡単に変更できます。
- 「Basic」では、HTTP メソッドを使用して、クライアントから認証情報を取得します。ユーザー名とパスワードは、サーバーで暗号化が設定されている (SSL が有効) 場合にのみ暗号化されます。それ以外の場合、ユーザー名とパスワードはクリアテキスト形式で送信され、傍受された場合は読み取られる可能性があります。
- 「SSL」では、クライアント証明書を使用してユーザーの認証を行います。このメソッドを使用するには、サーバーの SSL を有効にする必要があります。暗号化が有効になっている場合、基本メソッドと SSL メソッドを組み合わせて使用することができます。
- 「Digest」では、ユーザー名とパスワードをクリアテキストとして送信することなく、ブラウザでユーザー名とパスワードに基づいて認証を行えるようにする認証メカニズムを使用します。ブラウザは MD5 アルゴリズムを使用して、ユーザーのパスワードと Proxy Server によって提供される情報の一部を使用するダイジェスト値を作成します。このダイジェスト値は、サーバー側でダイジェスト認証プラグインを使用して計算され、クライアントによって提示されたダイジェスト値と比較されます。
- 「Other」では、アクセス制御 API を使用して作成するカスタムのメソッドを使用します。
- 「Authentication Database」では、サーバーでユーザーの認証に使用するデータベースを指定します。このオプションは、サーバーマネージャーからしか利用できません。「Default」を選択した場合、サーバーはデフォルトとして設定されているディレクトリサービス内のユーザーとグループを検索します。異なるデータベースを使用するように個々の ACL を設定する場合は、「Other」を選択し、データベースを指定します。server_root/userdb/dbswitch.conf でデフォルト以外のデータベースと LDAP ディレクトリを指定する必要があります。カスタムデータベースにアクセス制御 API を使用する場合は、「Other」を選択し、データベース名を入力します。
「From Host」の指定
どのコンピュータから要求が送られたかに基づいて、管理サーバーへのアクセスを制限できます。
ユーザーインタフェースの「Access Control Rules For」ページの「From Host」には、次の要素が表示されます。
「Only From」オプションを選択する場合は、「Host Names」フィールドまたは「IP Addresses」フィールドに、ワイルドカードパターンまたはコンマで区切ったリストを入力します。IP アドレスよりホスト名で制限する方が、より柔軟にできます。ユーザーの IP アドレスが変更された場合でも、このリストを更新する必要がありません。ただし、IP アドレスで制限する方が、より確実です。接続したクライアントの DNS 検索が失敗した場合、ホスト名による制限が使用できないためです。
コンピュータのホスト名または IP アドレスと一致するワイルドカードパターンとして使用できるのは、* というワイルドカード表記だけです。たとえば、指定ドメインのすべてのコンピュータに対してアクセスを許可または拒否する場合、*.example.com のように、特定ドメイン内のすべてのホストと一致するワイルドカードパターンを指定します。管理サーバーにアクセスするスーパーユーザーに対しては、その他のユーザーとは異なるホスト名と IP アドレスを設定することができます。
ホスト名の場合、* は名前の構成要素全体を表している必要があります。つまり、*.example.com は許容されますが、*users.example.com は許容されません。また、ホスト名で * を使用する場合、この記号は文字列の一番左に使用する必要があります。たとえば、*.example.com は許容されますが、users.*.com は許容されません。
IP アドレスの場合、* はアドレスのバイト全体を表している必要があります。たとえば、198.95.251.* は許容されますが、198.95.251.3* は許容されません。IP アドレスで * を使用する場合、この記号は文字列の一番右に使用する必要があります。たとえば、198.* は許容されますが、198.*.251.30 は許容されません。
プログラムへのアクセス制限
プログラムへのアクセスを制限できるのは、管理サーバーだけです。プログラムへのアクセス制限を適用すると、特定のユーザーだけがサーバーマネージャのページを参照し、そのサーバーを設定できるように制限できます。たとえば、一部の管理者に対して管理サーバーの「Users and Groups」セクションを設定することを許可するものの、「Global Settings」セクションへのアクセスは拒否するように制限することができます。
異なるユーザーが異なる機能ドメインにアクセスするように設定することもできます。選択したいくつかの機能ドメインへのアクセス権をユーザーに与えると、そのユーザーのログイン後、アクセス権を設定した機能ドメインの管理サーバーページのみがユーザーに表示されます。
ユーザーインタフェースの「Access Control Rules For」ページの「Programs」には、次の要素が表示されます。
アクセス権の設定
サーバーインスタンスに対するアクセス権を設定できるのは、サーバーマネージャーを使用した場合だけです。アクセス権は、サーバーのファイルやディレクトリへのアクセスを制限します。すべてのアクセス権の許可または拒否に加えて、一部のアクセス権の許可または拒否を行うための規則を指定することもできます。たとえば、ユーザーに対してファイルへの読み取り専用アクセスを許可することができます。この設定では、ユーザーは情報を表示することはできますが、ファイルを変更することはできません。
ユーザーインタフェースの「Access Control Rules For」ページの「Rights」には、次の要素が表示されます。
- 「All Access Rights」はデフォルトで、すべてアクセス権を許可または拒否します。
- 「Only The following Rights」では、許可または拒否するアクセス権の組み合わせを選択できます。
- 「Read」は、HTTP メソッドの GET、HEAD、POST、INDEX を含むファイルの表示をユーザーに許可します。
- 「Write」は、HTTP メソッドの PUT、DELETE、MKDIR、MOVE を含むファイルの変更または削除をユーザーに許可します。ファイルを削除するには、書き込み権と削除権の両方が必要です。
- 「Execute」は、ユーザーに CGI プログラム、Java アプレット、エージェントなどのサーバー側アプリケーションの実行を許可します。
- 「Remove」は、書き込み特権を持つユーザーにファイルやディレクトリの削除を行う権限を与えます。
- 「List」は、ユーザーに index.html ファイルが存在しないディレクトリ内のファイルリストへのアクセスを許可します。
- 「Info」は、ユーザーに URI (たとえば http_head) についての情報の取得を許可します。
カスタマイズされた式の作成
ACL には、カスタマイズされた式を入力できます。このオプションは、ACL ファイルの構文や構造をよく理解している場合にだけ選択してください。ACL ファイルを編集するか、カスタマイズされた式を作成する場合にだけ使用できる機能がいくつかあります。たとえば、時刻、曜日、またはその両方を基準として、サーバーへのアクセスを制限することができます。
次のカスタマイズされた式で、時刻や曜日によってアクセスを制限する方法を示します。この例では、LDAP ディレクトリに 2 つのグループが存在していることを前提としています。「regular」グループは、月曜から金曜の午前 8 時から午後 5 時までアクセスできます。「critical」グループはいつでもアクセスできます。
allow (read)
{
(group=regular and dayofweek="mon,tue,wed,thu,fri");
(group=regular and (timeofday>=0800 and timeofday<=1700));
(group=critical)
}有効な構文と ACL ファイルについては、「ACL ファイルの構文」を参照してください。
アクセス制御の解除
「Access Control Rules For」ページのオプション「Access control Is On」の選択を解除した場合、ACL のレコードの消去について確認するプロンプトが表示されます。「了解」をクリックすると、ACL ファイルから該当するリソースの ACL エントリが削除されます。
ACL を無効にする場合、generated-proxy-serverid.acl の各行の先頭に # 記号を使用することにより、ACL が記述された行をコメントにすることができます。
管理サーバーからアクセス制御を作成し、特定のサーバーインスタンスに対して有効に設定し、ほかのサーバーに対しては無効 (デフォルト) のままにしておくことができます。たとえば、管理サーバーからサーバーマネージャーページへのアクセスをすべて拒否することができます。デフォルトでは、ほかのサーバーに対して、分散管理は有効に、アクセス制御は無効に設定されます。管理者は管理サーバーを設定することはできませんが、ほかのサーバーにアクセスして設定することはできます。
アクセスが拒否された場合の応答
Proxy Server は、アクセスが拒否された場合、デフォルトメッセージを表示しますが、必要に応じて応答をカスタマイズできます。また、アクセス制御オブジェクトごとに異なるメッセージを作成することもできます。
管理サーバーの場合、デフォルトではユーザーは server_root/httpacl/admin-denymsg.html ファイルの「Permission Denied」メッセージを受け取ります。
権限拒否メッセージを変更するには
サーバーの一部へのアクセス制御この節では、サーバーとその内容に対して一般的に使用されている制限について説明します。各手順のステップごとに、必要な操作を詳細に説明します。ただし、「サーバーインスタンスに対するアクセス制御の設定」で説明するステップは実行しておく必要があります。
この節では、次の内容について説明します。
サーバー全体へのアクセス制限
グループ内のユーザーに対して、サブドメイン内のコンピュータからサーバーへのアクセスを許可したい場合があります。たとえば、ある会社のある部署のサーバーで、ネットワークの特定のサブドメインにあるコンピュータからのアクセスだけをユーザーに対して許可するような場合です。
サーバー全体へのアクセスを制限するには
サーバーインスタンスに対するアクセス制御の設定の節で説明した手順を使用して (「サーバーインスタンスに対するアクセス制御の設定」を参照)、次の操作を実行します。
- サーバーインスタンスのサーバーマネージャーにアクセスします。
- 「Preferences」タブで、「Administer Access Control」リンクをクリックします。
- ドロップダウンリストからサーバー全体を選択し、「Select」をクリックして、対応する「Edit」ボタンをクリックします。「Access Control Rules For」ページが表示されます。
- すべてのアクセスを拒否する、新しい規則を追加します。
- 特定のグループへのアクセスを許可する、別の新しい規則を追加します。
- 「From Host」を使用して、制限するホスト名および IP アドレスを指定します。
- 「Submit」をクリックして変更内容を保存します。
ディレクトリ (パス) へのアクセス制限
グループの所有者によって制御されている、ディレクトリ内のアプリケーションやサブディレクトリおよびファイルの読み取りまたは実行をグループ内のユーザーに許可することができます。たとえば、プロジェクトマネージャは、参照するプロジェクトチームのステータス情報を更新できます。
ディレクトリへのアクセスを制限するには
サーバーインスタンスに対するアクセス制御の設定の節で説明した手順を使用して (「サーバーインスタンスに対するアクセス制御の設定」を参照)、次の操作を実行します。
- サーバーインスタンスのサーバーマネージャーにアクセスします。
- 「Preferences」タブで、「Administer Access Control」リンクをクリックします。
- ドロップダウンリストから必要なリソースを選択し、「Edit」をクリックします。
- 新しい規則を作成し、デフォルト設定をそのまま使用して、すべての場所からのすべてのアクセスを拒否します。
- 特定のグループのユーザーに対して、読み取り権と実行権だけを許可する別の新しい規則を作成します。
- 特定のユーザーに対してすべてのアクセス権を許可する 3 つ目の新しい規則を作成します。
- 最後の 2 つの規則の「継続」の選択を解除します。
- 「Submit」をクリックして変更内容を保存します。
ファイルタイプへのアクセス制限
ファイルタイプに対してアクセスを制限できます。たとえば、特定のユーザーだけに、サーバーで実行されるプログラムの作成を許可することができます。すべてのユーザーがプログラムを実行できますが、作成や削除を実行できるのはグループ内の指定されたユーザーだけです。
ファイルタイプに対してアクセスを制限するには
サーバーインスタンスに対するアクセス制御の設定の節で説明した手順を使用して (「サーバーインスタンスに対するアクセス制御の設定」を参照)、次の操作を実行します。
ファイルタイプの制限については、両方の「継続」チェックボックスのチェックマークを付けたままにします。ファイルが要求されると、サーバーはまず ACL のファイルタイプを確認します。
Pathcheck 関数は obj.conf 内に作成されます。この関数には、ファイルまたはディレクトリのワイルドカードパターンが含まれている場合があります。ACL ファイルのエントリは、次のようになります。acl"*.cgi";
時刻に基づくアクセス制限
指定した時間または指定した日に、サーバーに対する読み取りアクセスと削除アクセスを制限することができます。
時刻に基づきアクセスを制限するには
サーバーインスタンスに対するアクセス制御の設定の節で説明した手順を使用して (「サーバーインスタンスに対するアクセス制御の設定」を参照)、次の操作を実行します。
- サーバーインスタンスのサーバーマネージャーにアクセスします。
- 「Preferences」タブで、「Administer Access Control」リンクをクリックします。
- 「Select A Resource」セクションのドロップダウンリストからサーバー全体を選択し、「Edit」をクリックします。
- すべてのユーザーに対して読み取り権と実行権を許可する、新しい規則を作成します。これは、ユーザーがファイルやディレクトリの追加、更新、または削除を行う場合にこの規則が適用されず、サーバーは一致する別の規則を検索することを意味します。
- すべてのユーザーに対して書き込み権と削除権を拒否する、別の規則を作成します。
- 「X」リンクをクリックして、カスタマイズされた式を作成します。
- アクセスを許可する曜日と時刻を入力します。その例を次に示します。
- 「Submit」をクリックして変更内容を保存します。カスタマイズされた式にエラーがあると、エラーメッセージが生成されます。修正してから、もう一度送信してください。
セキュリティに基づくアクセス制限
同じサーバーインスタンスに対して、SSL を使用する待機ソケットと SSL を使用しない待機ソケットを設定することができます。セキュリティに基づく制限を使用すると、セキュリティ保護されたチャネルを経由して送信する必要のあるリソースを保護できます。
セキュリティに基づきアクセスを制限するには
サーバーインスタンスに対するアクセス制御の設定の節で説明した手順を使用して (「サーバーインスタンスに対するアクセス制御の設定」を参照)、次の操作を実行します。
- サーバーインスタンスのサーバーマネージャーにアクセスします。
- 「Preferences」タブで、「Administer Access Control」リンクをクリックします。
- 「Select A Resource」セクションのドロップダウンリストからサーバー全体を選択し、「Edit」をクリックします。
- すべてのユーザーに対して読み取り権と実行権を許可する、新しい規則を作成します。これは、ユーザーがファイルやディレクトリの追加、更新、または削除を行う場合にこの規則が適用されず、サーバーは一致する別の規則を検索することを意味します。
- すべてのユーザーに対して書き込み権と削除権を拒否する、別の規則を作成します。
- 「X」リンクをクリックして、カスタマイズされた式を作成します。
- ssl="on" と入力します。その例を次に示します。
- 「Submit」をクリックして変更内容を保存します。カスタマイズされた式にエラーがあると、エラーメッセージが生成されます。修正してから、もう一度送信してください。
リソースへのアクセスのセキュリティ保護この節では、分散管理を有効にした後、Proxy Server でアクセス制御をセキュリティ保護するために必要な追加作業について説明します。
この節では、次の内容について説明します。
サーバーインスタンスへのアクセスのセキュリティ保護
サーバーインスタンスへのアクセスを制御するように Proxy Server を設定するには、server_root/httpacl/*.proxy-admserv.acl ファイルを編集して、アクセス制御権限を与えるユーザーを指定します。その例を次に示します。
acl "proxy-server_instance";
authenticate (user,group) {
database = "default";
method = "basic";
};
deny absolute (all) user != "UserA";IP ベースのアクセス制御の有効化
ip 属性を参照するアクセス制御エントリが、管理サーバーに関連する ACL ファイル (gen*.https-admserv.acl) にある場合は、次の手順 1、2 を実行してください。
ip 属性を参照するアクセス制御エントリが、サーバーインスタンスに関連する ACL ファイルにある場合は、その特定の ACL について次の手順 1 だけを実行してください。
IP ベースのアクセス制御を有効にするには
- server_root/httpacl/gen*.proxy-admserv.acl ファイルを次のように編集し、user と group に加えて、ip を認証リストに追加します。
acl "proxy-admserv";
authenticate (user,group,ip) {
database = "default";
method = "basic";
};- 次のアクセス制御エントリを追加します。
deny absolute (all) ip !="ip_for_which_access_is_allowed";
その例を次に示します。
acl "proxy-admserv";
authenticate (user,group,ip) {
database = "default";
method = "basic";
};
deny absolute (all) ip !="205.217.243.119";
ファイルベースの認証用 ACL の作成Proxy Server は、ファイルベースの認証データベースの使用をサポートしています。このデータベースには、ユーザーとグループに関する情報がテキスト形式でフラットファイルに格納されます。ACL のフレームワークは、ファイル認証データベースを利用できるように設計されています。
注
Proxy Server は動的フラットファイルをサポートしていません。フラットファイルデータベースは、サーバーの起動時に読み込まれます。ファイルへの変更は、サーバーを再起動した場合にだけ適用されます。
この節では、次の内容について説明します。
ACL エントリは、database キーワードを使用してユーザーデータベースを参照できます。その例を次に示します。
acl "default";
authenticate (user) {
...
database="myfile";
...
};server_root/userdb/dbswitch.conf ファイルには、ファイル認証データベースとその設定を定義するエントリが含まれています。その例を次に示します。
directory myfiledb file
myfiledb:syntax keyfile
myfiledb:keyfile /path/to/config/keyfile次の表は、ファイル認証データベースでサポートされるパラメータを示しています。
表 8-2 ファイル認証データベースがサポートするパラメータ
パラメータ
説明
構文
(オプション) 値は keyfile または digest のいずれか。省略した場合のデフォルト値は keyfile。
keyfile
(syntax=keyfile の場合は必須) ユーザーデータを含むファイルへのパス。
digestfile
(syntax=digest の場合は必須) ダイジェスト認証用のユーザーデータを含むファイルへのパス。
注
ファイルベースの認証データベースを使用して ACL を設定する前に、ファイルベースの認証ディレクトリサービスがすでに設定されていることを確認します。詳細は、「ディレクトリサービスの設定」を参照してください。
ファイル認証に基づくディレクトリサービス用 ACL の作成
ファイル認証に基づいてディレクトリサービス用 ACL を作成するには
- サーバーインスタンスのサーバーマネージャーにアクセスします。
- 「Preferences」タブで、「Administer Access Control」リンクをクリックします。
- ドロップダウンリストから ACL ファイルを選択し、「Edit」をクリックします。
- 「Access Control Rules For」ページで、編集する ACL エントリの「Users/Groups」リンクをクリックします。下のフレームに「Users/Groups」ページが表示されます。
- 認証データベースのドロップダウンリストから、鍵ファイルデータベースを指定します。
- 「Update」をクリックし、「Submit」をクリックして変更内容を保存します。
鍵ファイルベースのファイル認証データベースに対して ACL を設定すると、次のエントリ例のように、dbswitch.conf ファイルが ACL エントリで更新されます。
version 3.0;
acl "default";
authenticate (user) {
prompt = "Sun Java System Proxy Server 4.0";
database = "mykeyfile";
method = "basic";
};
deny (all) user = "anyone";
allow (all) user = "all";ダイジェスト認証に基づくディレクトリサービス用 ACL の作成
ファイル認証データベースは、RFC 2617 に規定されているダイジェスト認証での使用に適したファイル形式もサポートしています。パスワードとレルムに基づくハッシュが格納されます。クリアテキストのパスワードは保存されません。
ダイジェスト認証に基づいてディレクトリサービス用 ACL を作成するには
- サーバーインスタンスのサーバーマネージャーにアクセスします。
- 「Preferences」タブで、「Administer Access Control」リンクをクリックします。
- ドロップダウンリストから ACL ファイルを選択し、「Edit」をクリックします。
- 「Access Control Rules For」ページで、編集する ACL の「Users/Groups」リンクをクリックします。下のフレームに「Users/Groups」ページが表示されます。
- 認証データベースのドロップダウンリストから、ダイジェストデータベースを指定します。
- 「Update」をクリックし、「Submit」をクリックして変更内容を保存します。
ダイジェスト認証ベースのファイル認証データベースに対して ACL を設定すると、次のエントリ例のように、dbswitch.conf ファイルが ACL エントリで更新されます。
version 3.0;
acl "default";
authenticate (user) {
prompt = "filerealm";
database = "mydigestfile";
method = "digest";
};deny (all) user = "anyone";
allow (all) user = "all";