| Sun ONE Web Server 6.1 管理者ガイド |
第 9 章
サーバーへのアクセス制御この章では、管理サーバーや、Web サイト上に配置されたファイルやディレクトリへのアクセスを制御するためのさまざまな方法について説明します。たとえば、管理サーバーについては、マシンにインストールされているすべてのサーバーを完全に制御できるユーザーや、1 台以上のサーバーを部分的に管理できるユーザーを指定できます。管理サーバーでアクセス制御を使用するには、分散管理を有効にして、LDAP データベースに管理グループを設定する必要があります。この章では、すでに分散管理を設定していて、LDAP データベースにユーザーとグループを定義していることを前提としています。
第 4 章「Web コンテナと Web アプリケーションの J2EE ベースのセキュリティ」および第 6 章「証明書と鍵の使用」で説明されている Web サーバーのセキュリティについても、確認する必要があります。
この章では、次の項目について説明します。
アクセス制御とはアクセス制御を使用すると、次の内容を指定できます。
サーバー全体やサーバーの一部、または Web サイトのファイルやディレクトリへのアクセスを制御できます。アクセス制御エントリ (ACE) と呼ばれる規則の階層を作成します。これによって、アクセスを許可したり拒否したりすることができるようになります。各 ACE は、サーバーが階層内の次の ACE を確認する必要があるかどうかを指定します。作成する ACE の集合は、アクセス制御リスト (ACL) と呼ばれます。
デフォルトでは、サーバーには、複数の ACL が含まれる 1 つの ACL ファイルがあります。Sun ONE Web Server は、受信する要求に使用する仮想サーバーを指定したあと、その仮想サーバーに対して ACL が設定されているかどうかを確認します。現在の要求に適用される ACL が見つかった場合、Sun ONE Web Server は ACL に含まれる ACE を評価し、アクセスを許可するか拒否するかを決定します。
次の内容を基準にして、アクセスを許可または拒否します。
ユーザー - グループのアクセス制御の設定
特定のユーザーまたはグループに対して、Web サーバーへのアクセスを制限することができます。ユーザー - グループのアクセス制御を設定すると、ユーザーはユーザー名とパスワードを入力しないと、サーバーへのアクセス権を取得できなくなります。サーバーは、クライアント証明書の情報またはクライアント証明書自体を、ディレクトリサーバーのエントリと比較します。
管理サーバーでは、基本認証だけを使用します。管理サーバーでクライアント認証を要求する場合、obj.conf の ACL ファイルを手動で編集し、認証メソッドを SSL に変更する必要があります。
なお、( ) 内は画面上の表示を示しています。
これらすべてのメソッドで、ディレクトリサーバーが必要です。
ユーザー - グループ認証の場合、ユーザーは自分自身の認証を行わないと、管理サーバー、および Web サイト上のファイルやディレクトリにアクセスできません。クライアント証明書、またはダイジェスト認証プラグインを使用して認証を行う場合、ユーザーはユーザー名とパスワードを入力することによって識別情報を証明します。クライアント証明書を使用する場合は、暗号化が必要です。暗号化とクライアント証明書については、第 4 章「Web コンテナと Web アプリケーションの J2EE ベースのセキュリティ」を参照してください。
デフォルト認証 (Default)
デフォルト認証は、優先されるメソッドです。デフォルト設定では、obj.conf ファイルで指定したデフォルトメソッドを使用します。obj.conf でメソッドが設定されていない場合は、「基本」メソッドを使用します。「Default」チェックボックスにチェックマークを付けた場合、ACL 規則によって ACL ファイル内のメソッドが指定されることはありません。「Default」を選択すると、obj.conf ファイル内の 1 行を編集することによって、すべての ACL のメソッドを簡単に変更できます。
基本認証 (Basic)
基本認証では、Web サーバーまたは Web サイトにアクセスするユーザーに対して、ユーザー名とパスワードを要求します。これがデフォルトの設定です。Sun ONE Directory Server などの LDAP データベースにユーザーとグループのリストを作成して格納する必要があります。ここでは Web サーバーではなく、別のサーバールートにインストールされているディレクトリサーバー、またはリモートマシンにインストールされているディレクトリサーバーを使用する必要があります。
管理サーバー内、または Web サイト上のユーザー - グループ認証が設定されているリソースにユーザーがアクセスした場合、Web ブラウザにユーザー名とパスワードの入力を求めるダイアログボックスが表示されます。サーバーに対する暗号化が設定されているかどうかに応じて、サーバーはこの情報を暗号化された状態、または暗号化されていない状態で受信します。
ユーザーがサーバーに対して自分自身の認証を行う場合、次のダイアログが表示されます。
「OK」をクリックすると、次の内容が表示されます。
認証を受けていないユーザーが「Access Denied Response」ページで受信するアクセス拒否メッセージは、カスタマイズすることができます。
SSL 認証 (SSL)
サーバーは、次の 2 つの方法で、セキュリティ証明書付きのユーザーの識別情報を確認できます。
クライアントの認証で証明書の情報を使用するようにサーバーを設定した場合、サーバーは次の処理を実行します。
- まず、証明書が信頼できる CA から発行されたものであるかどうかを確認します。そうでない場合、認証は失敗し、トランザクションが終了します。クライアント証明書を有効にする方法については、「クライアント認証の要求」を参照してください。
- 証明書が信頼できる認証局 (CA) から発行されている場合は、certmap.conf ファイルを使用して、証明書をユーザーのエントリにマッピングします。証明書マッピングファイルの設定方法については、「certmap.conf ファイルの使用」を参照してください。
- 証明書が正しくマッピングされている場合は、そのユーザーに対して指定されている ACL 規則を確認します。証明書が正しくマッピングされている場合でも、ACL 規則によってユーザーのアクセスが拒否される可能性もあります。
特定のリソースへのアクセスを制御するためにクライアント認証を要求することは、サーバーへの接続のすべてに対してクライアント認証を要求することとは異なります。すべての接続に対してクライアント認証を要求するようにサーバーを設定した場合、クライアントは信頼できる CA によって発行された有効な証明書を提示するだけで済みます。ユーザーとグループの認証に SSL メソッドを使用するようにサーバーのアクセス制御を設定した場合、クライアントでは次の内容をすべて満たすことが必要です。
アクセス制御を使ってクライアント認証を要求する場合、Web サーバーでは SSL 暗号化方式を有効にする必要があります。SSL を有効にする方法については、第 6 章「証明書と鍵の使用」を参照してください。
SSL で認証されるリソースにアクセスするには、Web サーバーで信頼されている CA から、クライアント証明書が発行されている必要があります。ブラウザのクライアント証明書とディレクトリサーバーのクライアント証明書を比較するように Web サーバーの certmap.conf ファイルが設定されている場合、クライアント証明書はディレクトリサーバー内で発行されている必要があります。ただし、証明書から選択した情報とディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することもできます。たとえば、ブラウザ証明書のユーザー ID および電子メールアドレスとディレクトリサーバーのエントリだけを比較するように、 certmap.conf ファイルを設定することができます。certmap.conf と証明書のマッピングの詳細は、第 6 章「証明書と鍵の使用」を参照してください。
注
LDAP ディレクトリに対する証明書が確認されるため、SSL 認証メソッドだけは certmap.conf ファイルの修正を必要とします。サーバーへの接続のすべてに対してクライアント認証を要求するメソッドでは、この必要はありません。使用するクライアント証明書を選択する場合は、magnus.conf の AcceptTimeout 指令の値を大きくする必要があります。
ダイジェスト認証 (Digest)
ダイジェスト認証では、ユーザーがユーザー名とパスワードをプレーンテキスト形式 (暗号化されていない形式) で送信することなく、ユーザー名とパスワードに基づいた認証を行うことができます。ブラウザは、ユーザーのパスワードと Web サーバーによって提供される情報の一部を使用し、MD5 アルゴリズムによりダイジェスト値を作成します。このダイジェスト値は、サーバー側でもダイジェスト認証プラグインを使用して計算し、クライアントによって提示されたダイジェスト値と比較します。ダイジェスト値が一致する場合、ユーザーは認証を受けたものと見なします。
これが機能するには、ディレクトリサーバーがプレーンテキスト形式のユーザーのパスワードにアクセスできる必要があります。Sun ONE Directory Server にはリバーシブルパスワードプラグインが用意されています。このプラグインは、対称暗号化アルゴリズムを使用して格納時にデータを暗号化し、後にそれを元の形式に復号化することができます。データへの鍵を持っているのは Directory Server だけです。
ダイジェスト認証の場合は、リバーシブルパスワードプラグインと、Sun ONE Web Server 6.1 に組み込まれているダイジェスト認証に固有のプラグインを有効にする必要があります。ダイジェスト認証を処理するように Web サーバーを設定するには、dbswitch.conf でデータベース定義の digestauth プロパティを設定します。
サーバーは、指定されている ACL メソッドに基づいて、LDAP データベースに対して認証を試みます。表 9-1 を参照してください。ACL メソッドを指定しない場合、認証が必要であればダイジェスト認証または基本認証が使用され、認証が必要ない場合は基本認証が使用されます。基本認証が使用されるのは、これが優先されるメソッドのためです。
表 9-1 ダイジェスト認証要求の生成
ACL メソッド
認証データベースによってサポートされるダイジェスト認証
認証データベースによってサポートされないダイジェスト認証
デフォルト
指定なし
ダイジェストと基本
基本
基本
基本
基本
ダイジェスト
ダイジェスト
エラー
method = digest を指定して ACL を処理する場合、サーバーは次の内容を実行して認証を試みます。
UNIX でのダイジェスト認証プラグインのインストール
ダイジェスト認証プラグインは、次の両方に存在する共用ライブラリで構成されています。
UNIX でダイジェスト認証プラグインをインストールするには、次の手順を実行します。
- この共用ライブラリが、Sun ONE Web Server がインストールされているのと同じサーバーマシンにあることを確認します。
- Directory Manager のパスワードを確認します。
- /path/to へのすべての参照を、ダイジェストプラグインの共用ライブラリのインストール先に参照先が変更されるように、libdigest-plugin.ldif ファイルを修正します。
- プラグインをインストールするには、次のコマンドを入力します。
% ldapmodify -D "cn=Directory Manager" -w password -a < libdigest-plugin.ldif
Windows でのダイジェスト認証プラグインのインストール
ダイジェストプラグインとともに Sun ONE Directory Server を正常に起動できるようにするには、Sun ONE Web Server がインストールされている場所にある .dll ファイルを Sun ONE Directory Server のサーバーマシンにいくつかコピーする必要があります。
Windows でダイジェスト認証プラグインをインストールするには、次の手順を実行します。
DES アルゴリズムを使用するための Sun ONE Directory Server の設定
DES アルゴリズムは、ダイジェストパスワードが格納されている属性を暗号化するために必要です。
DES アルゴリズムを使用するように Sun ONE Directory Server を設定するには、次の手順を実行します。
その他の認証 (Other)
アクセス制御 API を使用すると、カスタム認証メソッドを作成できます。
ホスト - IP のアクセス制御の設定
管理サーバー、または Web サイトのファイルやディレクトリに対して、特定のコンピュータで動作しているクライアントだけが利用できるように、アクセスを制限できます。そのためには、アクセスの許可または拒否を行うコンピュータをホスト名または IP アドレスで指定します。ワイルドカードパターンを使用して、複数のコンピュータまたはネットワーク全体を指定することができます。ホスト - IP 認証を使用したファイルまたはディレクトリへのアクセスは、ユーザーが意識することなく行われます。このため、各ユーザーは、ユーザー名やパスワードを入力することなく、すぐにファイルやディレクトリにアクセスできます。
特定のコンピュータであっても複数のユーザーが使用しているため、ホスト - IP 認証は、ユーザー - グループ認証と組み合わせるとより効果的です。両方の認証メソッドが使用される場合は、アクセスするときにユーザー名とパスワードが要求されます。
ホスト - IP 認証では、サーバーが動作しているマシンで DNS を設定する必要はありません。ただし、ホスト - IP 認証を使用する場合は、ネットワーク上で DNS が稼働していて、この認証方式を使用するようにサーバーが設定されている必要があります。サーバーに対して DNS を有効にするには、サーバーマネージャの「Preferences」タブにある「Performance Tuning」ページを使用します。
DNS を有効にすると、サーバーで DNS ルックアップを実行する必要があるため、Sun ONE Web Server のパフォーマンスが低下します。サーバーパフォーマンスに対する DNS ルックアップの影響を小さくするには、すべての要求に対して IP アドレスを解決する代わりに、アクセス制御と CGI に対してだけ IP アドレスを解決します。このためには、obj.conf ファイルの AddLog fn="flex-log" name="access" を iponly=1 にします。
アクセス制御ファイルの使用
管理サーバーまたは Web サイト上のファイルやディレクトリに対してアクセス制御を使用する場合、拡張子が .acl のファイルに設定が格納されます。アクセス制御ファイルは install_dir/httpacl ディレクトリに格納されます。install_dir はサーバーがインストールされている場所です。たとえば、/usr/Sun/Servers にサーバーをインストールした場合、管理サーバーとサーバーに設定されている各サーバーインスタンスの両方の ACL ファイルが、/usr/Sun/Servers/httpacl/ に格納されます。
主要な ACL ファイルの名前は generated-https-server-id.acl で、一時的な作業ファイルは genwork-https-server-id.acl という名前です。Sun ONE 管理サーバーを使用してアクセスを設定する場合は、これらの 2 つのファイルが作成されます。ただし、複雑な制約が必要な場合は、複数のファイルを作成し、server.xml ファイルから参照することができます。また、時刻や曜日を基準にしたサーバーへのアクセス制限など、ファイルを編集することによって利用可能になる機能もいくつかあります。
また、.acl ファイルを手動で作成して編集し、API を使用してアクセス制御をカスタマイズすることもできます。アクセス制御 API の使用の詳細は、『Programmer's Guide』を参照してください。
アクセス制御ファイルとその構文については、付録 C 「ACL ファイルの構文」を参照してください。
ACL ユーザーキャッシュの設定
デフォルトでは、Sun ONE Web Server によるユーザーとグループの認証の結果が、ACL ユーザーキャッシュに保存されます。magnus.conf ファイルの ACLCacheLifetime 指令を使用して、ACL ユーザーキャッシュを有効にする期間を制御することができます。キャッシュのエントリが参照されるたびにその経過時間が計算され、ACLCacheLifetime と照合されます。経過時間が ACLCacheLifetime と同じか、それよりも長い場合、このエントリは使用されません。デフォルト値は 120 秒です。値を 0 (ゼロ) に設定すると、キャッシュが無効になります。この値に大きな値を使用する場合は、LDAP エントリを変更するたびに Sun ONE Web Server の起動が必要となる可能性があります。たとえば、この値を 120 秒に設定した場合は、Sun ONE Web Server と LDAP の同期が 2 分間に渡ってとられない可能性があります。LDAP ディレクトリが頻繁に変更される可能性が低い場合にだけ、大きな値を設定します。
magnus.conf の ACLUserCacheSize パラメータを使用すると、キャッシュ内に保存できるエントリの最大数を設定できます。このパラメータのデフォルト値は 200 です。新しいエントリがリストの先頭に追加され、キャッシュが最大サイズに達すると、新しいエントリを作成するために、このリストの最後のエントリが再利用されます。
また、magnus.conf に含まれるパラメータである ACLGroupCacheSize を使用して、ユーザーエントリごとにキャッシュできるグループメンバーの最大数を設定することができます。このパラメータのデフォルト値は 4 です。ただし、グループのメンバーではないユーザーはキャッシュされず、要求ごとに何回か LDAP ディレクトリにアクセスすることになります。
ACL ファイルの指令の詳細は、『NSAPI Programmer's Guide』を参照してください。
アクセス制御のしくみサーバーはページへの要求を受け取ると、ACL ファイルの規則を使用して、アクセスを許可するか拒否するか判断します。規則は、要求を送信しているコンピュータのホスト名や IP アドレスを参照できます。また、規則が LDAP ディレクトリに格納されているユーザーやグループを参照するように設定することもできます。
たとえば、次の ACL ファイルには、管理サーバー (admin-serv) に対する 2 つのデフォルトエントリと、「admin-reduced」グループ内のユーザーが管理サーバーの「Preferences」タブにアクセスできるようにするための追加エントリがあります。
たとえば、ユーザーが http://server_name/my_stuff/web/presentation.html という URL を要求したと仮定します。
Sun ONE Web Server はまず、サーバー全体へのアクセス制御を確認します。サーバー全体への ACL が認証の処理を続行するように設定される場合、サーバーは my_stuff ディレクトリへの ACL を確認します。ACL が存在する場合、サーバーは ACL 内の ACE を確認し、次のディレクトリに移動します。このプロセスは、アクセスを拒否する ACL が見つかるまで、または要求された URL の最後の ACL (この場合は、ファイル presentation.html) に達するまで続行します。
サーバーマネージャを使用してこの例のアクセス制御を設定するには、このファイルだけを対象とした ACL の作成のほか、ファイルへ誘導する各リソースの ACL を作成することができます。つまり、1 つはサーバー全体用、１ つは my_stuff ディレクトリ用、1 つは my_stuff/web ディレクトリ用、1 つはファイル用です。
アクセス制御の設定この節では、Web サイト上のファイルまたはディレクトリに対して、アクセスを制限するための手順を説明しています。すべてのサーバーに対してグローバルアクセス制御規則を設定することも、特定のサーバーに対して個別に設定することもできます。たとえば、人材管理部門を対象に、認証を受けているすべてのユーザーに各自の給与計算データを参照することは許可して、データを更新できるのは人材管理部門の給与計算担当者だけに制限する ACL を作成することができます。
管理サーバーによって、すべてのサーバーに対してグローバルにアクセス制御を設定することができます。次の節「アクセス制御オプションの選択」では、各オプションについて詳しく説明します。
グローバルなアクセス制御の設定
すべてのサーバーに対してグローバルにアクセス制御を作成したり編集したりするには、次の手順を実行します。
- 管理サーバーにアクセスして、「Global Settings」タブをクリックします。
- 「Restrict Access」リンクをクリックします。
- ドロップダウンリストから管理サーバー (https-admserv) を選択します。
- 「Create ACL」ボタン、および「Go」ボタンをクリックします。
「Access Control Rules for uri=/https-admserv/」ページが表示されます。
「Access Control Rules」ページ
管理サーバーには、編集できないデフォルトアクセス制御規則が 2 行あります。
- チェックマークが付いていない場合は、「Access control is on」チェックボックスにチェックマークを付けます。
- テーブルの最下行にデフォルトの ACL 規則を追加するには、「New Line」ボタンをクリックします。
アクセス制御制限を、その前のアクセス制御制限と置き換えるときは、上向き矢印をクリックします。
アクセス制御制限を、その後のアクセス制御制限と置き換えるときは、下向き矢印をクリックします。
- 「Users/Groups」列の「anyone」をクリックします。
下のフレームに「User/Group」ページが表示されます。
「User/Group」ページ
- アクセスを許可するユーザーやグループを選択し、「Update」をクリックします。
「Group」と「User」の「List」をクリックすると、選択肢のリストが表示されます。
- 「From Host」列の「anyplace」をクリックします。
- アクセスを許可するホスト名と IP アドレスを入力し、「Update」をクリックします。
- 「Programs」列で「All Programs」をクリックします。
「Programs」
- 「Program Groups」を選択するか、または「Program Items」フィールドにアクセスを許可する特定のファイル名を入力し、「Update」をクリックします。
- (省略可能) 「Extra」列の「x」をクリックして、カスタマイズした ACL 式を追加します。
- デフォルトとして選択されていない場合は、「Continue」列にチェックマークを付けます。
サーバーは次の行を評価してから、ユーザーがアクセスを許可されているかどうかを判断します。複数の行を作成する場合は、より一般的な制限からより特殊な制限へと処理を行います。
- (省略可能) 別の URL または URI の内容をユーザーに対して表示することを拒否する場合、「Response」をクリックします。
- 絶対 URL または相対 URI へのパスを入力し、「update」をクリックします。
サーバーインスタンスに対するアクセス制御の設定
サーバーマネージャを使用すると、特定のサーバーインスタンスに対するアクセス制御の作成、編集、または削除を実行できます。
注
削除する場合、ACL ファイルからすべての ACL 規則を削除しないでください。サーバーを起動するには、最小限の ACL 規則が含まれる ACL ファイルが少なくとも 1 つ必要です。すべての ACL 規則を削除してサーバーを再起動すると、構文エラーが発生します。
サーバーインスタンスに対してアクセス制御を作成するには、次の手順を実行します。
- サーバーマネージャにアクセスし、ACL を作成または編集するサーバーインスタンスを選択します。
- サーバーマネージャの「Preferences」タブを選択します。
- 「Restrict Access」リンクをクリックします。
- 「Option」列で、次のいずれかを選択します。
- 次のいずれかを選択します。
- リソースを選択し、ファイルまたはディレクトリのワイルドカードパターン (*.html など) を指定し、制限するディレクトリまたはファイル名を選択するか、またはファイルやディレクトリを参照します。
- 有効にしたすべての ACL のリストから選択する既存の ACL を選びます。有効にしていない既存の ACL は、このリストに表示されません。
- ACL 名を入力すると、名前付きの ACL を作成できます。このオプションは、ACL ファイルについての知識が豊富な場合にだけ使用します。名前付きの ACL をリソースに適用する場合、手動で obj.conf を編集する必要があります。
表 9-2 は、使用できるリソースワイルドカードと、その説明を示しています。
表 9-2 サーバーリソースのワイルドカード
リソースのワイルドカード
意味
デフォルト
インストール時に作成される名前付き ACL。LDAP ディレクトリ内のユーザーだけがドキュメントを発行できるように、書き込みアクセスを制限する
サーバー全体
1 組の規則によって、稼動中の仮想サーバーを含めた Web サイト全体へのアクセスが定義される。仮想サーバーへのアクセスを制限するには、そのドキュメントルートのパスを指定すること
/usr/sun/server4/docs/cgi-bin/*
cgi-bin ディレクトリ内のすべてのファイルとディレクトリへのアクセスを制御する。絶対パスを指定する必要がある。Windows では、パスにドライブ文字を含める必要がある
uri="/sales"
ドキュメントルートの sales ディレクトリへのアクセスを制御する。URI を指定するには、名前付き ACL を作成すること
- 「Edit Access Control」をクリックします。
「Access Control Rules for: (サーバーインスタンス)」が表示されます。
「Access Control Rules」ページ
- チェックマークが付いていない場合は、「Access control is on」チェックボックスにチェックマークを付けます。
- このサーバーインスタンス用の ACL を作成したり編集したりするには、「Action」列で「Deny」をクリックします。
下のフレームに「Allow/Deny」ページが表示されます。
「Allow/Deny」ページ
- デフォルトで選択されていない場合は「Allow」を選択し、「Update」をクリックします。
- 「Users/Groups」列の「anyone」をクリックします。
下のフレームに「User/Group」ページが表示されます。
「User/Group」ページ
- アクセスを許可するユーザーやグループを選択し、「Update」をクリックします。
「Group」と「User」の「List」をクリックすると、選択肢のリストが表示されます。
- 「From Host」列の「anyplace」をクリックします。
- アクセスを許可するホスト名と IP アドレスを入力し、「Update」をクリックします。
- 「Rights」列で「all」をクリックします。
「Access Rights」ページ
- 次のどちらかを選択し、「Update」をクリックします。
- (省略可能) 「Extra」列の「x」をクリックして、カスタマイズした ACL 式を追加します。
- デフォルトとして選択されていない場合は、「Continue」列にチェックマークを付けます。
サーバーは次の行を評価してから、ユーザーがアクセスを許可されているかどうかを判断します。複数の行を作成する場合は、より一般的な制限からより特殊な制限へと処理を行います。
- (省略可能) 別の URL または URI の内容をユーザーに対して表示することを拒否する場合、「Response」をクリックします。
- 絶対 URL または相対 URI へのパスを入力し、「Update」をクリックします。
- 「Submit」をクリックして、新しいアクセス制御規則を ACL ファイルに保存します。
- 目的の各サーバーインスタンスに対して上記のすべての手順を繰り返し、アクセス制御を確立します。
- 完了したら、「Apply」をクリックします。
- 「hard start /restart」または「dynamically apply」を選択します。
また、仮想サーバーごとに ACL 設定を有効にすることもできます。この実行方法については、「仮想サーバーのアクセス制御リストの編集」を参照してください。
アクセス制御オプションの選択次の節では、アクセス制御を設定するときに選択できる個々のオプションについて説明します。管理サーバーの場合は、最初の 2 行はデフォルトとして設定されていて、編集できません。
アクションの設定
要求がアクション制御規則と一致する場合にサーバーが実行するアクションを指定できます。
サーバーはアクセス制御式 (access control expressions、ACE) のリストを参照して、アクセス権を指定します。たとえば、最初の ACE は通常、すべてのユーザーを拒否します。最初の ACE に「continue」が設定されている場合、サーバーはリストの 2 番めの ACE を確認し、一致している場合は、次の ACE を確認します。「continue」チェックボックスにチェックマークが付いていない場合は、すべてのユーザーがリソースへのアクセスを拒否されます。サーバーは、一致しない ACE か、一致していても「continue」チェックボックスにチェックマークが付いていない ACE のどちらかに達するまでリストを参照します。一致する最後の ACE によって、アクセスが許可されるか拒否されるかが決まります。
ユーザーとグループの指定
ユーザーとグループの認証が行われる場合、ユーザーがアクセス制御規則で指定されているリソースにアクセスするには、ユーザー名とパスワードを入力する必要があります。
Sun ONE Web Server は、Sun ONE Directory Server などの LDAP サーバーに格納されているユーザーとグループのリストを確認します。
データベース内のすべてのユーザーに対してアクセスを許可または拒否することも、ワイルドカードパターンを使用して特定のユーザーに対してアクセスを許可または拒否することも、アクセスを許可または拒否する対象をユーザーとグループのリストから選択することもできます。
- 「Anyone (No Authentication)」はデフォルト値で、すべてのユーザーがユーザー名とパスワードを入力することなく、リソースにアクセスできることを意味します。ただし、ホスト名や IP アドレスなど、その他の設定に基づいてユーザーのアクセスが拒否される場合もあります。管理サーバーの場合、このオプションは、分散管理によって指定した管理者グループ内のすべてのユーザーがページにアクセスできることを意味します。
- 「Authenticated people only」
- 「All in the authentication database」は、データベースにエントリがあるユーザーに一致します。
- 「Only the following people」では、一致するユーザーとグループを指定できます。エントリをコンマ (,) で区切るか、またはワイルドカードパターンを使用すると、ユーザーとユーザーグループの任意のリストを作成することができます。また、データベースに格納されているユーザーやグループのリストから選択することもできます。「Group」は、指定したグループ内のすべてのユーザーに一致します。「User」は、指定した個々のユーザーに一致します。管理サーバーでは、ユーザーを分散管理のために指定した管理者グループのメンバーにする必要があります。
- 「Prompt for authentication」では、「authentication」ダイアログボックスに表示されるメッセージテキストを入力できます。このテキストを使用して、ユーザーが入力する必要のある項目について説明することができます。オペレーティングシステムによっては、最初の 40文字程度しか表示されない場合があります。Netscape Navigator と Netscape Communicator では、ユーザー名とパスワードがキャッシュに保存され、プロンプトのテキストと関連付けられます。同じプロンプトがあるファイルやディレクトリにユーザーがアクセスする場合は、ユーザー名とパスワードをもう一度入力する必要はありません。特定のファイルやディレクトリに対してユーザーが再び認証を受けるようにしたい場合、必要な操作はそのリソースの ACL に対するプロンプトを変更するだけです。
- 「Authentication Methods」では、クライアントから認証情報を取得するためにサーバーで使用するメソッドを指定します。管理サーバーで使用できるのは、認証の基本メソッドだけです。
- 「Default」では、obj.conf ファイルで指定したデフォルトメソッドを使用します。obj.conf でメソッドが設定されていない場合は、「Basic」メソッドを使用します。「Default」チェックボックスにチェックマークを付けた場合、ACL 規則によって ACL ファイル内のメソッドが指定されることはありません。「Default」を選択すると、obj.conf ファイル内の 1 行を編集することによって、すべての ACL のメソッドを簡単に変更できます。
- 「Basic」では、HTTP メソッドを使用して、クライアントから認証情報を取得します。ユーザー名とパスワードが暗号化されるのは、サーバー側で暗号化するように設定されている場合だけです。
- 「SSL」では、クライアント証明書を使用してユーザーの認証を行います。このメソッドを使用するには、サーバー側で SSL を有効にする必要があります。暗号化するように設定されている場合は、基本メソッドと SSL メソッドを組み合わせて使用することができます。
- 「Digest」では、ユーザー名とパスワードをプレーンテキストとして送信することなく、ブラウザでユーザー名とパスワードに基づいて認証を行えるようにする認証機構を使用します。ブラウザは MD5 アルゴリズムを使用して、ユーザーのパスワードと Web サーバーによって提供される情報の一部を使用するダイジェスト値を作成します。このダイジェスト値は、サーバー側でダイジェスト認証プラグインを使用して計算され、クライアントによって提示されたダイジェスト値と比較されます。
- 「Other」では、アクセス制御 API を使用して作成するカスタム認証メソッドを使用します。
- 「Authentication Database」では、サーバーでユーザーの認証に使用するデータベースを選択します。このオプションを使用できるのは、サーバーマネージャを使用する場合だけです。「Default」を選択した場合、サーバーはデフォルトとして設定されているディレクトリサービス内のユーザーとグループを検索します。複数のデータベースを使用するように個々の ACL を設定する場合、「Other」を選択し、ドロップダウンリストでデータベースを選択します。デフォルト以外のデータベースと LDAP ディレクトリは、server_root/userdb/dbswitch.conf ファイルで指定されている必要があります。Oracle や Informix などのカスタムデータベースにアクセス制御 API を使用する場合は、「Other」を選択し、データベース名を入力します。
From Host の指定
どのコンピュータから要求されたかに基づいて、管理サーバーや Web サイトへのアクセスを制限できます。
「Only from」オプションを選択する場合は、「Host Names」フィールドまたは「IP アドレス」フィールドに、ワイルドカードパターンまたはコンマで区切ったリストを入力します。ホスト名に基づく制限は、IP アドレスに基づく制限よりも柔軟性があります。ユーザーの IP アドレスが変更された場合でも、このリストを更新する必要はありません。ただし、IP アドレスによる制限には、より高い信頼性があります。これは、接続されているクライアントを対象とした DNS 検索に失敗した場合、ホスト名によるアクセス制限が機能しなくなるためです。
コンピュータのホスト名または IP アドレスと一致するワイルドカードパターンとして使用できるのは、* というワイルドカード表記だけです。たとえば、指定ドメインのすべてのコンピュータに対してアクセスを許可するか、または拒否する場合、*.sun.com のように特定ドメイン内のすべてのホストと一致するワイルドカードパターンを指定します。管理サーバーにアクセスしているスーパーユーザーに対しては、その他のユーザーとは異なるホスト名と IP アドレスを設定することもできます。
ホスト名については、* が名前のコンポーネント全体を表現していなくてはなりません。つまり、*.sun.com は許容されますが、*users.sun.com は許容されません。また、ホスト名で * を使用する場合、この記号を文字列の一番左に使用する必要があります。たとえば、*.sun.com は許容されますが、users.*.com は許容されません。
IP アドレスについては、* がアドレスのバイト全体を表現していなくてはなりません。たとえば、198.95.251.* は許容されますが、198.95.251.3* は許容されません。IP アドレスで * を使用する場合、この記号を文字列の一番右に使用する必要があります。たとえば、198.* は許容されますが、198.*.251.30 は許容されません。
プログラムへのアクセス制限
プログラムへのアクセスを制限できるのは、管理サーバーだけです。プログラムへのアクセス制限を適用すると、特定のユーザーだけがサーバーマネージャのページを参照し、そのサーバーを設定できるように制限できます。たとえば、一部の管理者に対して管理サーバーの「Users & Groups」セクションを設定することを許可するものの、「Global Settings」へのアクセスは拒否するように制限することができます。
異なるユーザーが異なる機能ドメインにアクセスするように設定することもできます。選択したいくつかの機能ドメインへのアクセス権をユーザーに設定すると、そのユーザーのログイン後、そのユーザーにアクセスを許可した機能ドメインだけから管理サーバーページを表示できます。
アクセス権の設定
サーバーインスタンスに対するアクセス権を設定できるのは、サーバーマネージャを使用した場合だけです。アクセス権は、Web サイトのファイルやディレクトリへのアクセスを制限します。すべてのアクセス権の許可または拒否に加えて、一部のアクセス権の許可または拒否を行うための規則を指定することもできます。たとえば、ユーザーに対してファイルへの読み取り専用アクセスを許可することができます。この設定では、ユーザーは情報を参照することはできますが、ファイルを変更することはできません。
- 「All Access Rights」はデフォルトで、すべてのアクセス権を承認または拒否します。
- 「Only the following rights」では、許可、または拒否するアクセス権の組み合わせを選択できます。
- 「Read」は、ユーザーにファイルの参照を許可します。これには、GET、HEAD、POST、および INDEX の HTTP メソッドが含まれます。
- 「Write」は、ユーザーにファイルの変更や削除を許可します。これには PUT、DELETE、MKDIR、RMDIR、および MOVE の HTTP メソッドが含まれます。ファイルを削除するには、書き込み権と削除権の両方が必要です。
- 「Execute」は、ユーザーに CGI プログラム、Java アプレット、エージェントなどのサーバー側アプリケーションの実行を許可します。
- 「Delete」は、書き込み権を持つユーザーにファイルやディレクトリの削除を行う権限を与えます。
- 「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 ファイルについては、付録 C 「ACL ファイルの構文」および「obj.conf での ACL ファイルの参照」を参照してください。
アクセス制御の解除
「Access control is on」チェックボックスのチェックマークを外した場合、ACL 内のレコードを消去するかどうかを確認するプロンプトが表示されます。「OK」をクリックすると、サーバーは ACL ファイルから該当するリソースの ACL エントリを削除します。
ACL を無効にしたい場合、generated-https-server-id.acl ファイルの各行の先頭に # 記号を挿入することによって、ACL が記述された行をコメントにすることができます。
管理サーバーからアクセス制御を作成し、特定のサーバーインスタンスに対して有効に設定し、ほかのサーバーに対しては無効 (デフォルト) のままにしておくことができます。たとえば、管理サーバーからサーバーマネージャページへのアクセスをすべて拒否することができます。デフォルトでは、ほかのサーバーに対して、分散管理は有効に、アクセス制御は無効に設定されます。管理者は管理サーバーを設定することはできませんが、ほかのサーバーにアクセスして設定することはできます。
注
このアクセス制御は、管理者グループのユーザーに対して、分散管理のために設定されます。管理サーバーはまず、ユーザー (スーパーユーザーを除く) が管理者グループのメンバーであることを確認してから、アクセス制御規則を評価します。
アクセスが拒否された場合の応答
アクセスが拒否された場合、Sun ONE Web Server は「FORBIDDEN. Your client is not allowed access to the restricted object.」というデフォルトメッセージを出力します。別の応答メッセージを選択することもできます。また、アクセス制御オブジェクトごとに異なるメッセージを作成することもできます。
特定の ACL に送信されるメッセージを変更するには、次の手順を実行します。
サーバーの一部へのアクセス制御この節では、Web サーバーとその内容に対して一般的に使用されているアクセス制限について説明します。各制限の手順では、実行する必要のある操作を詳細に説明しています。ただし、「サーバーインスタンスに対するアクセス制御の設定」で説明している手順も、すべて実行する必要があります。
この節で説明する制限を次に示します。
サーバー全体に対するアクセス制限
呼び出されたグループ内のユーザーに対して、サブドメイン内のコンピュータからサーバーへのアクセスを許可したい場合があります。たとえば、ある会社のある部署のサーバーで、ネットワークの特定のサブドメインにあるコンピュータからのアクセスだけをユーザーに対して許可したい場合です。
サーバーインスタンスに対するアクセス制御の設定の節で説明した手順を使用して、次の操作を実行します。
- サーバーマネージャを使用して、サーバーインスタンスを選択します。
- 「Preferences」タブを選択します。
- 「Restrict Access」リンクをクリックします。
- 編集する ACL ファイルを選択します。
- サーバーリソース全体を選択し、「Edit Access Control」をクリックします。
- すべてのアクセスを拒否する、新しい規則を追加します。
- 特定のグループへのアクセスを許可する、別の新しい規則を追加します。
- アクセスを許可するコンピュータのホスト名として、ワイルドカードパターンを入力します。
たとえば、「*.employee.sun.com」と入力します。
- 「Continue」チェックボックスのチェックマークを外します。
- 変更を送信して、適用します。
ディレクトリ (パス) へのアクセス制限
グループの所有者によって制御されているディレクトリおよびサブディレクトリにある、ファイルやアプリケーションの読み取りまたは実行をグループ内のユーザーに許可することができます。たとえば、プロジェクトマネージャは、参照するプロジェクトチームのステータス情報を更新できます。
サーバーのディレクトリへのアクセスを制限するには、サーバーインスタンスに対するアクセス制御の設定に関する節で説明した手順を使用して、次の操作を実行します。
- サーバーマネージャを使用して、サーバーインスタンスを選択します。
- 「Preferences」タブを選択します。
- 「Restrict Access」リンクをクリックします。
- 編集する ACL ファイルを選択します。
- 「Pick a Resource」セクションを参照して、アクセスを制限するディレクトリを選択します。
サーバーのドキュメントルート内のディレクトリが表示されます。選択すると、「Editing」ドロップダウンリストにディレクトリへの絶対パスが表示されます。
- 「Edit Access Control」をクリックします。
- 新しい規則を作成し、デフォルト設定をそのまま使用して、すべての場所からのすべてのアクセスを拒否します。
- 特定のグループのユーザーに対して、読み取り権と実行権だけを許可する別の新しい規則を作成します。
- 3 行目を作成し、特定のユーザーに対してすべてのアクセス権を許可します。
- 2 行目と 3 行目の「Continue」チェックボックスのチェックマークを外して、「Update」をクリックします。
- 変更を送信して、適用します。
ファイルまたはディレクトリへの絶対パスが docroot ディレクトリに作成されます。ACL ファイルのエントリは、次のようになります。
acl "path=d:¥sun¥suitespot¥docroot1¥sales/";URI (パス) へのアクセス制限
URI を使用して、Web サーバー上のシングルユーザーのコンテンツへのアクセスを制御することができます。URI は、サーバーのドキュメントルートディレクトリを始点とした、相対的なパスとファイル名です。サーバーのコンテンツのすべて、または一部 の名前 (たとえば、ディスクのボリューム名) を頻繁に変更したり削除したりする場合、URI を使用すると簡単です。また、ほかにドキュメントルートがある場合にも、URI を使用するとアクセス制御を簡単に行えます。
URI へのアクセスを制限するには、サーバーインスタンスに対するアクセス制御の設定に関する節で説明した手順を使用して、次の操作を実行します。
- サーバーマネージャを使用して、サーバーインスタンスを選択します。
- 「Preferences」タブを選択します。
- 「Restrict Access」リンクをクリックします。
- 「ACL name」セクションの「Type」に、アクセスを制限する URI を入力します。
例 : uri=/my_directory
- 「Edit Access Control」をクリックします。
- すべてのユーザーに対して読み取りアクセスを許可する、新しい規則を作成します。
- ディレクトリの所有者に対してアクセスを許可する、別の規則を作成します。
- 1 番目の規則と 2 番目の規則の両方の「Continue」チェックボックスのチェックマークを外します。
- 「Submit and Apply your changes」をクリックします。
ドキュメントルートに対して相対的な URI へのパスが作成されます。ACL ファイルのエントリは、次のようになります。
acl "uri=/my_directory";
ファイルタイプに対するアクセス制限
ファイルのタイプに基づいて、サーバーまたは Web サイトへのアクセスを制限することができます。たとえば、特定のユーザーだけに、サーバーで実行されるプログラムの作成を許可することができます。すべてのユーザーがプログラムを実行できますが、作成や削除を実行できるのはグループ内の指定されたユーザーだけです。
アクセスできるファイルタイプを制限するには、サーバーインスタンスに対するアクセス制御の設定に関する節で説明した手順を使用して、次の操作を実行します。
ファイルタイプの制限については、両方の「Continue」チェックボックスのチェックマークを付けたままにします。ファイルが要求されると、サーバーはまず、ACL のファイルタイプを確認します。
Pathcheck 関数は obj.conf 内に作成されます。この関数には、ファイルまたはディレクトリのワイルドカードパターンが含まれる場合あります。ACL ファイルのエントリは、次のようになります。
acl "*.cgi";
時刻に基づくアクセス制限
指定した日の指定した時間に、サーバーに対する読み取りアクセスと削除アクセスを制限することができます。この制限を使用して、ファイルがアクセスされている可能性がある勤務時間中には、ユーザーがファイルを変更したり削除したりできないようにすることができます。
時刻を基にしてアクセスを制限するには、サーバーインスタンスに対するアクセス制御の設定に関する節で説明した手順を使用して、次の操作を実行します。
- サーバーマネージャを使用して、サーバーインスタンスを選択します。
- 「Preferences」タブを選択します。
- 「Restrict Access」リンクをクリックします。
- 「Pick a Resource」ドロップダウンリストから「entire server」を選択して、「Edit Access Control」をクリックします。
- すべてのユーザーに対して読み取り権と実行権を許可する、新しい規則を作成します。
これは、ユーザーがファイルやディレクトリの追加、更新、または削除を行う場合にはこの規則が適用されず、サーバーは該当する別の規則を検索することを意味します。
- すべてのユーザーに対して書き込み権と削除権を拒否する、別の規則を作成します。
- 「X」リンクをクリックして、カスタマイズされた式を作成します。
- アクセスを許可する曜日と時刻を入力します。
その例を次に示します。
カスタム式を作成すると、「Unrecognized expressions」メッセージが「Users/Groups」フィールドと「From Host」フィールドに表示されます。
- 変更を送信して、適用します。
カスタマイズした式にエラーがあると、エラーメッセージが生成されます。修正してから、もう一度送信してください。
セキュリティに基づくアクセス制限
Sun ONE Web Server 6.1 では、1 つのサーバーインスタンスに SSL を使用する待機ソケットと SSL を使用しない待機ソケットを設定することができます。セキュリティに基づく制限を使用すると、セキュリティ保護されたチャネルを経由して送信する必要のあるリソースを保護できます。
セキュリティに基づいてアクセスを制限するには、サーバーインスタンスに対するアクセス制御の設定に関する節で説明した手順を使用して、次の操作を実行します。
- サーバーマネージャを使用して、サーバーインスタンスを選択します。
- 「Preferences」タブを選択します。
- 「Restrict Access」リンクをクリックします。
- 「Pick a Resource」ドロップダウンリストから「entire server」を選択して、「Edit Access Control」をクリックします。
- すべてのユーザーに対して読み取り権と実行権を許可する、新しい規則を作成します。
これは、ユーザーがファイルやディレクトリの追加、更新、または削除を行う場合にはこの規則が適用されず、サーバーは該当する別の規則を検索することを意味します。
- すべてのユーザーに対して書き込み権と削除権を拒否する、別の規則を作成します。
- 「X」リンクをクリックして、カスタマイズされた式を作成します。
- 「ssl="on"」と入力します。
その例を次に示します。
- 変更を送信して、適用します。
カスタマイズした式にエラーがあると、エラーメッセージが生成されます。修正してから、もう一度送信してください。
分散管理によるアクセス制御のセキュリティ保護
ここでは、分散管理を有効にした後で、Sun ONE Web Server 6.1 でアクセス制御でセキュリティを保護するために必要な追加タスクについて説明します。
リソースへのアクセスのセキュリティ保護
generated.https-server-id.acl ファイルの https-server-id オブジェクトタグに指定されている PathCheck 指令の実行順序によって、リソースに対して不適切なアクセス権が与えられてしまうことがあります。これを防止するには、<server-root>/generated.https-server-id.acl をアクセス制御が必要なプログラムグループをコンマで区切って次のように指定します。
allow (all)
user=<username> and program=<program group, program group...>;
上の行の下に、次の行を追加します。
deny absolute (all)
user=<username> and program!=<program group, program group...>;
サーバーインスタンスへのアクセスのセキュリティ保護
サーバーインスタンスへのアクセスを制御するように Sun ONE Web Server 6.1 を設定するには、<server-root>/httpacl/*.https-admserv.acl ファイルを編集して、アクセス制御権限を与えるユーザーを指定します。その例を次に示します。
acl "https-<instance>";
authenticate (user,group) {
database = "default";
method = "basic";
};
deny absolute (all) user != "UserA";
IP ベースのアクセス制御の有効化
アクセス制御エントリが、管理サーバーに関連する ACL ファイル (gen*.https-admserv.acl) の ip 属性を参照する場合、次の手順 1、2 を実行してください。
アクセス制御エントリが、サーバーインスタンスに関連する ACL ファイルの ip 属性を参照する場合は、その ACL について次の手順 1 だけを実行してください。
- <server-root>/httpacl/gen*.https-admserv.acl ファイルを次のように編集して、user と group に加えて、ip を認証リストに追加します。
acl "https-admserv";
authenticate (user,group,ip) {
database = "default";
method = "basic";
};
- 次のアクセス制御エントリを追加します。
deny absolute (all) ip !="ip_for_which_access_is_allowed";
その例を次に示します。
acl "https-admserv";
authenticate (user,group,ip) {
database = "default";
method = "basic";
};
deny absolute (all) ip !="205.217.243.119";
ダイナミックアクセス制御ファイルの使用サーバーのすべてのコンテンツが 1 人のユーザーによって管理されることはほとんどありません。このため、Sun ONE Web Server へのアクセス権を与えることなく、一般ユーザーが必要な設定を行えるように、設定オプションのサブセットへのアクセスを許可することが必要な場合があります。設定オプションのサブセットは、ダイナミック設定ファイルに保存されます。
この節で説明する内容を次に示します。
.htaccess ファイルの使用
Sun ONE Web Server は、ダイナミック設定ファイルである .htaccess をサポートします。ユーザーインタフェースから、または設定ファイルを手動で変更することによって、.htaccess ファイルを有効にすることができます。.htaccess をサポートするファイルは、server_root/plugins/htaccess ディレクトリにあります。これらのファイルには、.htaccess ファイルと、.nsconfig ファイルを .htaccess ファイルに変換するためのスクリプトを使用できるようにするプラグインが含まれています。
.htaccess ファイルは、サーバーの標準アクセス制御と組み合わせて使用することができます。標準アクセス制御は、PathCheck 指令の順序に関係なく、必ず .htaccess アクセス制御の前に適用されます。ユーザー-グループ認証が「基本」の場合、ユーザー認証には標準アクセス制御と .htaccess アクセス制御の両方は必要ありません。標準サーバーアクセス制御を経由して SSL クライアント認証を使用でき、.htaccess ファイルを経由して HTTP「基本」認証を要求することもできます。
この節では、次の内容について説明します。
ユーザーインタフェースからの .htaccess の有効化
.htaccess を使用するように Sun ONE Web Server を設定するには、次の手順を実行します。
- サーバーマネージャにアクセスし、.htaccess を有効にするサーバーインスタンスを選択します。
- 画面の一番上にある「Class Manager」リンクをクリックします。
- 「Content Mgmt」タブを選択します。
- .htaccess Configuration」リンクをクリックします。
- 次の方法で、編集するサーバーを選択します。
- 「Yes」を選択して、.htaccess を有効にします。
- htaccess の設定を追加するファイルの名前を入力します。
- 「OK」をクリックします。
- 完了したら、「Apply」をクリックします。
- 「hard start /restart」または「dynamically apply」を選択します。
magnus.conf からの .htaccess の有効化
.htaccess を使用するサーバーを手動で有効にするにはまず、プラグインを読み込んで初期化してから起動するように、サーバーの magnus.conf ファイルを修正する必要があります。
- server_root/https-server_name/config ファイルの magnus.conf を開きます。
- ほかの Init 指令のあとに、必要な行を追加します。
- UNIX/Linuxの場合は、次の行を追加します。
Init fn="load-modules" funcs="htaccess-init,htaccess-find"
shlib="server_root/plugins/htaccess/htaccess.so" NativeThread="no"
Init fn="htaccess-init"- Windowsの場合は、次の行を追加します。
Init fn="load-modules" funcs="htaccess-init,htaccess-find,htaccess-register"
shlib="server_root/plugins/htaccess/htaccess.dll" NativeThread="no"
Init fn="htaccess-init"- HPの場合は、次の行を追加します。
Initfn="load-modules" funcs="htaccess-init,htaccess-find,htaccess-register" shlib="<server_root>/plugins/htaccess/htaccess.sl" NativeThread="no"
- (省略可能) 最後の行を次のように編集します。
Init fn="htaccess-init"[groups-with-users=yes]
- 「File」の「Save」をクリックします。
- obj.conf を開きます。
- オブジェクトの最後の指令として、PathCheck 指令を追加します。
- 仮想サーバーによって管理されるすべてのディレクトリに対して .htaccess ファイルの処理を有効にするには、object.conf ファイルのデフォルトオブジェクトに PathCheck 指令を追加します。
<Object name="default">
...
PathCheck fn="htaccess-find"
</Object>
.htaccess の処理をオブジェクトの最後の PathCheck 指令にする必要があります。
- サーバー上の特定のディレクトリを対象とした .htaccess ファイルの処理を有効にするには、magnus.conf 内の対応する定義に PathCheck 指令を配置します。
- .htaccess ファイルに .htaccess 以外の名前を付けるには、次の形式を使用して PathCheck 指令でファイル名を指定する必要があります。
PathCheck fn="htaccess-find" filename="filename"
それ以降のサーバーへのアクセスは、指定されたディレクトリでの .htaccess によるアクセス制御の対象となります。たとえば、.htaccess ファイルへの書き込みアクセスを制限するには、対象ファイルの設定スタイルを作成し、その設定スタイルに対してアクセス制御を適用します。詳細は、第 17 章「設定スタイルの適用」を参照してください。
既存の .nsconfig ファイルの .htaccess ファイルへの変換
Sun ONE Web Server 6.1 には、旧バージョンで使用していた既存の .nsconfig ファイルを .htaccess ファイルに変換するための htconvert プラグインが組み込まれています。Sun ONE Web Server 6.1 では、.nsconfig ファイルはサポートされなくなりました。このため、これまで .nsconfig ファイルを使用していた場合は、.htaccess ファイルに変換する必要があります。
htconvert が有効になっている場合、pfx2dir 指令と document-root 指令に対して、指定された server.xml ファイルが検索されます。検出された各 .nsconfig ファイルは、.htaccess ファイルに変換されます。設定によっては、複数の obj.conf ファイルを変換できます。
注
既存の .htaccess ファイルがある場合、htconvert によって htaccess.new ファイルが生成され、警告メッセージが表示されます。.htaccess と .htaccess.new がすでに存在している場合、新しいファイルは .htaccess.new.new という名前になります。つまり .new は繰り返し追加されます。
現在、htconvert プラグインは RestrictAccess 指令と RequireAuth 指令、および <Files> ラッパーだけをサポートしています。<Files*> 以外の <Files> がある場合は、警告メッセージが表示され、スクリプトはディレクトリ内のすべてのファイルへのアクセスが制御されるように動作します。
ファイルを変換するには、コマンドプロンプトで、使用しているシステムの Perl へのパス、プラグインスクリプトへのパス、server.xml ファイルへのパスを入力します。その例を次に示します。
すべての .nsconfig ファイルが .htaccess ファイルに変換されますが、変換元のファイルが削除されることはありません。
groups-with-users オプションによって、多数のユーザーをグループとして処理できます。多数のユーザーがグループのメンバーとなっている場合は、次の手順を実行します。
また、次のように実行することもできます。
htaccess-register の使用
htaccess-register は、認証メソッドを独自に作成するための新しい関数です。Apache と同様に、外部認証モジュールを作成し、htaccess-register を使用して .htaccess モジュールに組み込むことができます。server_root/plugins/nsapi/htaccess に 2 つのサンプルモジュールがあります。
外部モジュールを使用すると、1 つまたは複数の新しい指令を作成できます。たとえば、認証のためのユーザーデータベースを指定できます。ただし、指令を <Limit> タグまたは <LimitExcept> タグで囲むことはできません。
.htaccess ファイルの例
次に、.htaccess ファイルの例を示します。
<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName mxyzptlk.kawaii.com
AuthUserFile /server_root/mxyz-docs/service.pwd
AuthGroupFile /server_root/mxyz-docs/service.grp
サポートされる .htaccess 指令
このバージョンでは、次の .htaccess 指令がサポートされます。
allow
構文
Allows from host: host は次のいずれかです。
<Limit> または <LimitExcept> で囲む必要はありませんが、通常は囲まれています。
効果
指定したホストに対してアクセスを許可します。通常、<Limit> タグで囲まれています。
deny
構文
Deny from host: host は次のいずれかです。
<Limit> タグまたは <LimitExcept> タグで囲む必要はありませんが、通常は囲まれています。
効果
指定したホストに対してアクセスを拒否します。通常、<Limit> タグで囲まれています。
AuthGroupFile
構文
AuthGroupFile filename: filename は、groupname: user user という形式でグループ定義が含まれるファイルの名前です。
<Limit> タグや <LimitExcept> タグで囲むことはできません。
効果
指定されたグループファイルが、require group 指令で参照されるグループ定義で使用されることを示します。AuthGroupFile 指令で指定されたファイル名が AuthUserFile 指令で指定されたファイル名と同じである場合、このファイルには次の形式でユーザーとグループが含まれると想定されることに注意してください。
username:DES-encrypted-password:comma-separated-list-of-groups
AuthUserFile
構文
AuthUserFile filename: 次のように指定します。
<Limit> タグや <LimitExcept> タグで囲むことはできません。
効果
指定されたユーザーファイルが、require user 指令または require valid-user 指令で参照されるユーザー名で使用されることを示します。
obj.conf の Init fn=htaccess-init 指令で groups-with-users=yes を使用したり、同じファイル名で AuthGroupFile 指令を指定したりすると、そのファイルが次の形式であると想定されることに注意してください。
username:DES-encrypted-password:comma-separated-list-of-groups
AuthName
構文
AuthName authentication realm: authentication realm は、ユーザー認証の要求に関連付けられる認証領域を指定する文字列です。
<Limit> タグや <LimitExcept> タグで囲むことはできません。
効果
authentication realm 文字列は、通常、クライアント側のユーザー名とパスワードのプロンプトに表示されます。クライアントのユーザー名とのパスワードのキャッシュへの保存に影響を与える場合があります。
AuthType
構文
AuthType Basic: <Limit> タグや <LimitExcept> タグで囲むことはできません。
効果
ユーザー認証メソッドとして、現在サポートされている唯一のメソッドである HTTP 基本認証を指定します。
<Limit>
構文
<Limit method method ...>
allow, deny, order, or require directives
</Limit>
method は GET、POST、PUT などの HTTP メソッドです。ここでは、Web サーバーに対して使用できるすべてのメソッドを使用できます。
効果
指定された HTTP メソッドを使用する要求に対してだけ、タグで囲まれている指令が適用されます。
<LimitExcept>
構文
<LimitExcept method method ...>
allow, deny, order, or require directives
</LimitExcept>
method は GET、POST、PUT などの HTTP メソッドです。ここでは、Web サーバーに対して使用できるすべてのメソッドを使用できます。
効果
指定された HTTP メソッドと一致しないタイプの要求に対してだけ、タグで囲まれている指令が適用されます。
order
構文
Order ordering。ordering は次のいずれかです。
<Limit> または <LimitExcept> で囲む必要はありませんが、通常は囲まれています。
効果
require
構文
<Limit> または <LimitExcept> で囲む必要はありませんが、通常は囲まれています。
効果
.htaccess セキュリティに関する注意事項
デフォルトでは、サーバーによる HTTP PUT のサポートが無効になっています。クラスマネージャの「Content Mgmt」の「Remote File Manipulation」ページを使用して、HTTP PUT を有効にすることができます。.htaccess ファイルが保存されているディレクトリへの PUT アクセスを許可する場合、このファイル自体の置換も許可することになるため、細心の注意が必要です。アクセスを制限することによって、ディレクトリ内のすべてのファイルに対する PUT アクセスを防止することができます。「ディレクトリ (パス) へのアクセス制限」を参照してください。
仮想サーバーへのアクセス制御Sun ONE Web Server 6.1 のアクセス制御についての情報は、各仮想サーバーの ACL ファイルと、ドキュメントディレクトリの .htaccess ファイルから入手できます。.htaccess システムは iPlanet Web Server 4.x から変更されていません。
server.xml ファイルには、特定の標準 Sun ONE Web Server 6.x ACL ファイルに関連付けられた ID を定義する、1 つまたは複数の ACLFILE タグが含まれています。その例を次に示します。
<ACLFILE id="standard" file="standard.acl">
アクセス制御を使用する仮想サーバーの場合は、「aclids」プロパティに 1 つまたは複数の ACL ファイル ID への参照を作成する必要があります。その例を次に示します。
<VS aclids=都tandard��gt;
この設定では、複数の仮想サーバーで同じ ACL ファイルを共有することができます。仮想サーバーに対するユーザー-グループ認証を要求する場合は、その定義に 1 つまたは複数の USERDB タグを追加する必要があります。このような USERDB タグは、ACL ファイル内のデータベース名と dbswitch.conf 内の実際のデータベースを関連付けます。
次の例では、「database」属性のない ACL を dbswitch.conf の「default」データベースにマッピングします。
<VS>
<USERDB id=電efault��database=電efault��>
</VS>
仮想サーバーからデータベースへのアクセス
dbswitch.conf ファイルで、ユーザー認証データベースをグローバルに定義できます。このファイルは、サーバーの起動時に読み込まれます。
dbswitch.conf 内の LDAP URL の baseDN は、データべースへのすべてのアクセスのグローバルルートを定義します。これによって、下位互換が維持されます。最新のインストールでは、baseDN には何も指定されません。
dcsuffix は dbswitch.conf 内の LDAP データベースの新しい属性で、Sun ONE LDAP スキーマに従って DC ツリーのルートを定義します。これは、LDAP URL の baseDN に対する相対位置になります。dcsuffix 属性が存在する場合、LDAP データベースは Sun ONE LDAP スキーマに準拠し、動作の一部が変更されます。Sun ONE LDAP スキーマの詳細と例については、『Sun ONE Web Server 6.1 Administrator's Configuration Reference』の第 2 章に記載されている「The Sun ONE LDAP Schema」を参照してください。
仮想サーバーごとに、ディレクトリの 1 つを指定する 1 つまたは複数の USERDB ブロックを定義できます。また、追加情報を定義することもできます。USERDB ブロック ID は、ACL のデータベースパラメータから参照することができます。仮想サーバーに USERDB ブロックがない場合、ユーザーまたはグループを基準にした ACL は失敗します。
USERDB タグは、ACL のデータベース属性と dbswitch.conf の間の間接参照の追加層を定義します。間接参照のこの層では、仮想サーバーの管理者がアクセスするデータベースをサーバー管理者が完全に制御するために必要な保護を追加します。
USERDB の詳細については、『Sun ONE Web Server 6.1 Administrator's Configuration Reference』の第 2 章に記載されている「User Database Selection」を参照してください。
ユーザーインタフェースでの LDAP データベースの指定
dbswitch.conf で 1 つまたは複数のユーザー認証データベースを定義すると、クラスマネージャを使用して、各仮想サーバーが認証のためにどのデータベースを使用するかを設定できるようになります。また、クラスマネージャを使用して、仮想サーバーでの認証のために dbswitch.conf での設定に対して新しく作成したデータベース定義を追加することができます。
LDAP データベースまたは仮想サーバーで使用するデータベースを指定するには、次の手順を実行します。
- サーバーマネージャにアクセスし、「Virtual Server Class」タブを選択します。
- 「Tree View of the Server」のリストから、LDAP データベースを指定したい仮想サーバークラスのリンクをクリックします。
- 表示されていない場合は、「Virtual Servers」タブを選択します。
- 「ACL Settings」リンクをクリックします。
「ACL Settings for Virtual Servers」ページが表示されます。
- 表示されていない場合は、「Option」列のドロップダウンリストから「Edit」を選択します。
- 編集している仮想サーバーの「Database」列でドロップダウンリストからデータベース設定を選択します。
- 「OK」をクリックします。
- 「Edit ACL Files」ウィンドウを閉じます。
- 「Apply」をクリックします。
- 「dynamically apply」を選択します。
仮想サーバーのアクセス制御リストの編集
仮想サーバーの ACL は、仮想サーバーがあるサーバーインスタンスに対して作成されます。仮想サーバーの ACL 設定は、サーバーインスタンスに対して作成される ACL 設定のデフォルトとなります。ただし、各仮想サーバーのアクセス制御はクラスマネージャから編集できます。また、このメソッドを使用して、新しく作成された ACL ファイルを仮想サーバーに追加します。
仮想サーバーの ACL 設定を編集するには、次の手順を実行します。
- サーバーマネージャにアクセスし、「Virtual Server Class」タブを選択します。
- 「Tree View of the Server」のリストから、LDAP データベースを指定したい仮想サーバークラスのリンクをクリックします。
- 表示されていない場合は、「Virtual Servers」タブを選択します。
- 「ACL Settings」リンクをクリックします。
- 変更する仮想サーバーの「Option」フィールドのドロップダウンリストから「Edit」または「Delete」を選択します。
- 「ACL File」フィールドの「Edit」リンクをクリックすると、使用できる ACL ファイルが表示されます。
- 仮想サーバーに追加または削除する 1 つまたは複数の ACL ファイルを選択します。
仮想サーバーには複数のドキュメントルートが存在する場合があるため、複数の ACL ファイルが存在する可能性があります。
- ドロップダウンリストから、ACL リストに関連付けるデータベースを選択します。
- (必要に応じて) BaseDN を入力します。
- 変更が終わったら、「OK」をクリックします。
- 「Apply」をクリックします。
- 「dynamically apply」を選択します。
ファイルベースの認証用 ACL の作成Sun ONE Web Server 6.1 は、ファイルベース認証データベースの使用をサポートしています。このデータベースには、ユーザーとグループに関する情報がテキスト形式のフラットファイルとして格納されます。ACL のフレームワークは、ファイル認証データベースを利用できるように設計されています。
注
Sun ONE Web Server は、ダイナミックフラットファイルをサポートしていません。フラットファイルデータベースは、サーバーの起動時に読み込まれます。ファイルに加えた変更は、サーバーを再起動した場合にだけ適用されます。
ACL エントリは、database キーワードを使用してユーザーデータベースを参照できます。その例を次に示します。
acl "default";
authenticate (user) {
...
database="myfile";
...
};
myfile データベースは、server-root/userdb/dbswitch.conf ファイル内の対応する定義とリンクしている server.xml 内の VS の USERDB 要素中で参照するようにできます。その例を次に示します。
<VS>
...
<USERDB id="myfile" database="myfiledb">
...
</VS>
server-root/userdb/dbswitch.conf ファイルには、ファイル認証データベースとその設定を定義するエントリが含まれます。その例を次に示します。
directory myfiledb file
myfiledb:syntax keyfile
myfiledb:keyfile /path/to/config/keyfile
次の表を参照してください。
表 9-3 ファイル認証データベースがサポートするパラメータ
syntax
[省略可能] 値は keyfile、digest、または htaccess。省略した場合のデフォルト値は keyfile
keyfile
[syntax=keyfile の場合は必須] ユーザーデータを含むファイルへのパス
digestfile
[syntax=digest の場合は必須] ダイジェスト認証用のユーザーデータを含むファイルへのパス
groupfile
[syntax=htaccess の場合は必須] AuthGroupFile へのパス
userfile
[syntax=htaccess の場合は必須] AuthUserFile へのパス
警告
ファイル認証データベースファイル (htaccess、digestfile、または keyfile) で許可されている一行の長さの上限は 255 バイトです。
この制限を超える行がある場合、サーバーは起動に失敗し、ログファイルにエラーが記録されます。
注
ACL がファイルベース認証データベースを使用するように設定する前に、次の前提条件が満たされることを確認してください。
- ファイルベースの認証ディレクトリサービスがすでに設定されている。方法については、「ディレクトリサービスの設定」を参照
- ACL が設定される仮想サーバーが、必要となるファイルベース認証データベース (keyfile、htaccess、または digestauth) のファイルタイプを使用する。このように設定しない場合、デフォルトとして設定されているディレクトリサービスに対して ACL 制限が設定されます。
ファイル認証に基づくディレクトリサービス用の ACL の作成
ファイル認証に基づいてディレクトリサービス用の ACL エントリを作成するには、次の手順を実行します。
- サーバーマネージャにアクセスし、ACL を作成または編集するサーバーインスタンスを選択します。
- サーバーマネージャの「Preferences」タブを選択します。
- 「Restrict Access」リンクをクリックします。
- 「Option」列の下で、ドロップダウンリストから ACL ファイルを選択し、「Edit ACL」をクリックします。
- 「Access Control Rules」ページの上部フレームで、編集する ACL の「Users/Groups」リンクをクリックします。
- 「User/Group」ページの下部フレームで、「Authentication database」ドロップダウンリストから「keyfile」を選択します。
- 「Update」をクリックします。
keyfile ベースのファイル認証データベースに対して ACL を設定すると、次のエントリ例のように、dbswitch.conf ファイルが ACL エントリで更新されます。
version 3.0;
acl "default";
authenticate (user) {
prompt = "Sun One Web Server 6.1";
database = "mykeyfile";
method = "basic";
};
deny (all) user = "anyone";
allow (all) user = "all";
.htaccess 認証に基づくディレクトリサービス用の ACL の作成
Sun ONE Web Server は、.htaccess ベースのフラットファイル認証をサポートしています。これまで .htaccess 認証を使用していた場合は、既存のデータファイルを変更せずに、ファイル認証データベースに移行できます。「.htaccess ファイルの使用」でも説明したように、.htaccess のユーザーとグループのデータは、1 つのファイルに格納することも、2 つのファイル (ユーザーデータ用とグループデータ用) に分割することもできます。ファイル認証データベースでは、両方の形式がサポートされます。
htaccess 認証に基づいてディレクトリサービス用の ACL エントリを作成するには、次の手順を実行します。
- サーバーマネージャにアクセスし、ACL を作成または編集するサーバーインスタンスを選択します。
- サーバーマネージャの「Preferences」タブを選択します。
- 「Restrict Access」リンクをクリックします。
- 「Option」列の下で、ドロップダウンリストから ACL ファイルを選択し、「Edit ACL」をクリックします。
- 「Access Control Rules」ページの上部フレームで、編集する ACL の「Users/Groups」リンクをクリックします。
- 「User/Group」ページの下部フレームで、「Authentication database」ドロップダウンリストから「htaccess」を選択します。
- 「Update」をクリックします。
htaccess ベースのファイル認証データベースに対して ACL を設定すると、次のエントリ例のように、dbswitch.conf ファイルが ACL エントリで更新されます。
version 3.0;
acl "default";
authenticate (user) {
prompt = "Sun One Web Server 6.1";
database = "myhtaccessfile";
method = "basic";
};
deny (all) user = "anyone";
allow (all) user = "all";
ファイル認証データベースへの既存の .htaccess 情報の移行
既存の .htaccess 情報を Sun ONE Web Server 6.1 のファイル認証データベースに移行するには、次の手順を実行します。
ユーザーファイルの形式は次のとおりです。
#user:password
グループファイルの形式は次のとおりです。
#group1:user1 user2
#group2:user3 user4
ユーザーファイルとグループファイルの名前が同じ場合は、次に示す行の構文で両方のファイルを 1 つにまとめることができます。
#user:password:group1,group2
htaccess データベースの例
例 1
#sample userfile (user/password "j2ee/j2eepwd" user/password "user1/user1pwd" )
j2ee:9hmjfRwNxvJLU
user1:wvQirF86BsjSk
例 2
#sample group file
staff:j2ee user1
eng:j2ee
例 3
#sample user/group file (username "j2ee", user password "j2eepwd")
j2ee:9hmjfRwNxvJLU:staff,eng
ダイジェスト認証に基づくディレクトリサービス用の ACL の作成
ファイル認証データベースは、RFC 2617 に規定されているダイジェスト認証での使用に適したファイル形式もサポートしています。ハッシュはパスワードに基づき、レルムは格納されます。プレーンテキストパスワードは維持されません。
digestauth ベースの認証に基づいてディレクトリサービス用の ACL エントリを作成するには、次の手順を実行します。
- サーバーマネージャにアクセスし、ACL を作成または編集するサーバーインスタンスを選択します。
- サーバーマネージャの「Preferences」タブを選択します。
- 「Restrict Access」リンクをクリックします。
- 「Option」列の下で、ドロップダウンリストから ACL ファイルを選択し、「Edit ACL」をクリックします。
- 「Access Control Rules」ページの上部フレームで、編集する ACL の「Users/Groups」リンクをクリックします。
- 「User/Group」ページの下部フレームで、「Authentication database」ドロップダウンリストから「digest」を選択します。
- 「Update」をクリックします。
digestauth ベースのファイル認証データベースに対して 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";
