|
| Sun ONE Application Server 7 セキュリティ管理者ガイド |
HTTP サーバーアクセス制御の管理この章では、HTTP サーバーリソースへのアクセス制御のメカニズムと管理手順について説明します。
注 この章の内容は J2EE アプリケーションには適用できません。J2EE アプリケーションを開発するときは、J2EE の仕様書と『Sun ONE Application Server 開発者ガイド』に記載されているセキュリティメカニズムを参照してください。
この節には次のトピックがあります。
- HTTP サーバーのアクセス制御について
- ダイジェスト認証の実装
- ホスト - IP 認証の実装
- ACL ファイルの操作
- クライアント認証の設定
- ACL/ACE の設定
- obj.conf ファイル内の ACL ファイルの参照
- ACL ユーザーキャッシュの設定
- サーバーインスタンスのアクセス制御の設定
- サーバー内の領域へのアクセスの制限
- アクセス制御の無効化
- アクセス拒否時の応答
- 仮想サーバーのアクセス制御
- htaccess ファイルの使用
HTTP サーバーのアクセス制御について
アクセス制御とは、誰に、どんな Sun ONE Application Server へのアクセス権を与えるかを制御することによって、製品の安全を確保する方法です。たとえば、マシンにインストールされているすべてのサーバーを完全に制御できるのが誰で、一部のサーバーを部分的に制御できるのが誰であるかを指定できます。
注 管理サーバーにアクセス制御を適用する前に、管理グループを設定します。この節の解説は、ディレクトリデータベースにユーザーとグループがすでに定義されていることを前提としています。
アクセスの許可と拒否は、次の情報に基づきます。
- 誰が要求しているか
- どこから要求が発せられているか
- いつ要求が発生しているか (時間帯など)
- どのような接続が使われているか (SSL など)
HTTP サーバーへのアクセスを制御するセキュリティメカニズムには、さまざまな認証制限や ACL ファイルが含まれます。
この節には次のトピックがあります。
HTTP サーバーのユーザー - グループ認証
ユーザー - グループ認証では、アクセスを許可する前にユーザーがユーザー自身を認証する必要があります。これは、ユーザーが名前とパスワードを入力し、クライアント証明書またはダイジェスト認証プラグインを使うことで行われます。Sun ONE Application Server が受け取るこの情報が暗号化されるかどうかは、サーバーで暗号化が有効になっているかどうかによって異なります。
注 J2EE アプリケーションでは、ユーザー - グループ認証にはレルム (セキュリティドメイン) が使われます。J2EE アプリケーションのセキュリティレルムの開発については、『Sun ONE Application Server 開発者ガイド』を参照してください。
デフォルトの認証は、obj.conf ファイルに指定した方式です。方式が obj.conf ファイルに指定されていない場合は、基本認証となります。
認証方式をデフォルトに設定すると、ACL 規則は認証方式を ACL ファイルに指定しません。デフォルトを選択することで、obj.conf ファイルの 1 行を編集するだけですべての ACL の認証方式を変更できます。
デフォルトを選択すると便利です。
ユーザー - グループ認証には 3 つの方式があり、そのすべてがディレクトリサーバーを必要とします。
- 基本認証
- SSL 認証
- ダイジェスト認証
注 管理サーバーにクライアント認証を義務づけるときは、obj.conf ファイルの ACL ファイルを編集し、方式を SSL に変更します。クライアント認証の詳細については、「クライアント認証の設定」を参照してください。
基本認証
基本認証では、Sun ONE Application Server または Web サイトにアクセスするユーザーは、ユーザー名とパスワードを入力する必要があります。まず、ユーザーとグループのリストを作成して Sun ONE Directory Server などの LDAP データベースに格納します。ディレクトリサーバーは、Sun ONE Application Server とは異なるサーバールートにインストールするか、リモートマシンにインストールする必要があります。
基本認証はデフォルトの認証方式です。
注 SSL 暗号化を有効にせずに基本認証を選択すると、ユーザー名とパスワードは暗号化されずにテキストとしてネットワークに流されます。このため、ネットワークパケットが傍受され、ユーザー名とパスワードが盗まれる危険があります。基本認証は、SSL 暗号化、またはホスト - IP 認証、あるいはその両方と組み合わせた利用が最も効果的です。ダイジェスト認証を使うことで、この問題を回避できます。
SSL 認証
SSL 認証では、Sun ONE Application Server はユーザーのセキュリティ証明書を使ってユーザーの識別情報を確認します。これは、次の方法で行われます。
- クライアント証明書に含まれる情報を識別情報の証明とする
- クライアント証明書がディレクトリに公開されていることを確認する (必要に応じて)
クライアントの認証に証明書の情報を使うように設定すると、Sun ONE Application Server は次の処理を実行します。
- その証明書が信頼できる証明書発行局 (CA) から発行されていることを検証する。そうでない場合、認証は失敗し、トランザクションを終了する
- 証明書が信頼できる証明書 CA から発行されている場合は、certmap.conf ファイルを使って証明書をユーザーのエントリにマッピングする。証明書マッピングファイルの設定方法については、「certmap.conf ファイルの操作」を参照
- 証明書が正しくマッピングされると、そのユーザーに設定されている ACL 規則を調べる
注 証明書が正しくマッピングされても、ACL 規則によってそのユーザーのアクセスが拒否されることがあります。
ユーザー - グループの SSL 認証
サーバーのアクセス制御にユーザー - グループ SSL 認証方式を設定した場合は、次の条件を満たす必要があります。
- 信頼できる CA が発行した有効な証明書が存在する
- ディレクトリデータベースに記録されている有効なユーザーに証明書が正しくマッピングされる
- アクセス制御リスト (ACL) による適切な評価が行われる
特定リソースにアクセスするクライアントの SSL 認証
特定リソースへのアクセスを制御するクライアント認証は、サーバーへのすべての接続を制御するクライアント認証とは異なります。すべての接続に対するクライアント認証をサーバーに義務づけた場合、クライアントは信頼できる CA が発行した有効な証明書を使うだけで認証されます。クライアント認証を有効にする方法については、「クライアント認証の設定」を参照してください。
クライアントの SSL 認証を設定する場合は、そのサーバーで有効な SSL 暗号化方式が必要となります。詳細については、「SSL と TLS の有効化」を参照してください。
SSL 認証を必要とするリソースにアクセスするには、サーバーが信頼する CA から発行されたクライアント証明書が必要です。ブラウザのクライアント証明書とディレクトリサーバー内のクライアント証明書を比較するように certmap.conf ファイルを設定した場合は、ディレクトリサーバーにクライアント証明書が公開されている必要があります。ただし、証明書の特定の情報だけをディレクトリサーバー内の情報と比較するように certmap.conf ファイルを設定することもできます。たとえば、ブラウザ証明書に記録されているユーザー ID と電子メールアドレスだけをディレクトリサーバー内の情報と比較するように certmap.conf ファイルを設定できます。certmap.conf ファイルと証明書のマッピングについては、「certmap.conf ファイルの操作」を参照してください。
ダイジェスト認証
ダイジェスト認証は、ユーザー名とパスワードを通常のテキストとして送信せずに、通常テキスト形式のユーザー名とパスワードに基づいてユーザーを認証する認証方式です。ブラウザは、MD5 アルゴリズムを使って、ユーザーのパスワードなどの情報からダイジェスト値を作成します。ダイジェスト値はサーバー側のダイジェスト認証プラグインでも計算され、クライアントからのダイジェスト値と比較されます。ユーザーは、ダイジェスト値が一致する場合に認証されます。
これが正しく機能するには、サーバーがユーザーのパスワードを通常のテキストとして取得することが必要です。Sun ONE Directory Server には、対称暗号化アルゴリズムを使ってデータを暗号化する可逆化パスワードプラグインが用意されています。データは後から元の形式に復号されます。Sun ONE Directory Server だけが、このデータのキーを保持します。
method=digest で ACL を処理する場合、サーバーは次のプロセスで認証を行います。
- 認証要求ヘッダーをチェックする - 見つからない場合はエラーとなり、ダイジェスト認証の形跡を残して処理は停止する
- 認証タイプをチェックする - 認証タイプがダイジェストの場合、サーバーは次の処理を行う
ディレクトリデータベースを使った認証は、次の表に示す ACL 方法に基づいて行われます。
ダイジェスト認証のマトリクス
設定されている ACL 方法
認証 DB がダイジェスト認証をサポートする
認証 DB がダイジェスト認証をサポートしない
デフォルト指定なし
ダイジェスト、基本
基本
基本
基本
基本
ダイジェスト
ダイジェスト
ERROR
詳細は、「ホスト - IP 認証の実装」を参照してください。
ホスト - IP 認証
ホスト - IP アクセス制御は、管理サーバーまたは Web サイト上のファイルやディレクトリへのアクセスを、特定のコンピュータを使うクライアントだけに制限する方法です。この場合は、アクセスを許可または拒否するコンピュータのホスト名または IP アドレスを指定します。ワイルドカードのパターンを使って、複数のコンピュータやネットワーク全体を指定することもできます。
ユーザー名やパスワードを入力せずに、ファイルやディレクトリに直ちにアクセスできるため、ホスト - IP 認証はユーザーにはシームレスに感じられます。詳細は、「ホスト - IP 認証の実装」を参照してください。
アクセス制御リスト (ACL) ファイル
ACL ファイルは、Sun ONE Application Server に格納されているリソースにアクセスできるユーザーの ID リストを記録したテキスト形式のファイルです。ACE (アクセス制御エントリ) という階層構造の規則を作成することで、個人、グループ、または特定のサーバーやアプリケーションなどのエンティティからのアクセスを許可したり、拒否したりすることができます。それぞれの ACE は、サーバーがその階層の次の ACE を調べるかどうかを指定します。作成した ACE のセットを ACL (アクセス制御リス
ト)と呼びます。デフォルトの設定では、Sun ONE Application Server はサーバーにアクセスするすべてのリストをまとめた 1 つの ACL ファイルを使用します。複数の ACL ファイルを作成し、obj.conf ファイルでそれを参照させることもできます。
Sun ONE Application Server がページに対する要求を受け取ると、ACL ファイルに記述されている規則に基づいてアクセス可能であるかどうかが決定されます。この規則は、要求を送信するコンピュータのホスト名または IP アドレスを参照することができます。また、Sun ONE Directory Server などの LDAP ディレクトリに保存されているユーザーやグループを規則に参照させることもできます。
送られてきた要求にどの仮想サーバーを利用するかが決定すると、Sun ONE Application Server は、その仮想サーバーに ACL が設定されているかどうかを調べます。その要求に適用される ACL が見つかると、Sun ONE Application Server は ACE に基づいて、アクセスを許可するか、または拒否するかを決定します。
ACL の使用については、「ACL ファイルの操作」を参照してください。
クライアント認証
クライアント認証を有効にするときは、問い合わせに対してサーバーが応答を送信する前に、クライアントの証明書が必要となります。Sun ONE Application Server は、クライアント証明書に記録されている CA と、クライアント証明書に署名している信頼できる CA の一致によりクライアント証明書の認証を行います。
Sun ONE Application Server がクライアントから要求を受け取ると、処理を開始する前にクライアントの証明書を要求します。要求の送信時にクライアント証明書を同時に送信するクライアントもあります。
注 クライアント証明書を LDAP にマッピングする前に、必要な ACL を設定する必要があります。ACL の詳細については、「ACL ファイルの操作」を参照してください。
- Sun ONE Application Server は、管理サーバーに記録されている信頼できる CA のリストから CA を検索します。
一致する CA が存在しない場合は、Sun ONE Application Server は接続を終了します。
- 一致する CA が存在する場合は、サーバーは要求の処理を継続します。
- 証明書が信頼できる CA から発行されていることを確認すると、サーバーは次の方法で証明書を LDAP エントリーにマッピングします。
クライアント証明書に記録されている発行者と対象 DN を、LDAP ディレクトリの分岐ポイントにマッピングする
クライアント証明書の対象 (エンドユーザー) に関する情報と一致する項目を、LDAP ディレクトリから検索する
LDAP 検索の方法は、certmap.conf という証明書マッピングファイルに指定されています。マッピングファイルは、クライアント証明書ファイルからどの値 (ユーザー名、電子メールアドレスなど) を検索するかを指定します。サーバーは、この値を使って LDAP ディレクトリからユーザー情報を検索します。ただし、検索前に LDAP ディレクトリの内のどの場所から検索を開始するかを決定する必要があります。検索を開始する場所は、証明書マッピングファイルによって指定されます。
(オプション) DN に対応する LDAP エントリに含まれる証明書と、クライアント証明書を比較する
- 検索を開始する場所と検索項目が決定すると、サーバーは LDAP ディレクトリの検索を開始します。一致するエントリがない場合、または複数のエントリが一致する場合は、検索は失敗し、証明書の認証は行われません。
予定の処理を ACL に指定しておくことができます。たとえば、証明書の検索が失敗した場合に、管理者だけを受け入れるように Sun ONE Application Server を設定できます。ACL の詳細設定については、を参照してください。
- LDAP ディレクトリに一致するエントリと証明書が存在する場合は、サーバーはその情報を使ってトランザクションを処理します。たとえば、証明書と LDAP のマッピングを使ってサーバーへのアクセスを許可します。
実装については、「クライアント認証の設定」を参照してください。
ダイジェスト認証の実装
ダイジェスト認証の仕組みを十分に理解していない場合は、「ダイジェスト認証」を参照してください。
ダイジェスト認証では、Sun ONE Application Server に用意されている、可逆化パスワードプラグインと digestauth に固有のプラグインを有効にする必要があります。ダイジェスト認証を処理するようにサーバーを設定するには、dbswitch.conf ファイルの digestauth データベース定義プロパティを設定します。
次の各項では、ユーザー - グループのダイジェスト認証の実装に必要なタスクについて説明します。
ダイジェスト認証プラグインの実装
ダイジェスト認証プラグインは、libdigest-plugin.lib および libdigest-plugin.ldif にある共有ライブラリから構成されます。
UNIX 環境でのダイジェスト認証
ダイジェスト認証プラグインを UNIX 環境にインストールするには、次の手順を実行します。
- Sun ONE Directory Server がインストールされているサーバーマシンに上記共有ライブラリが存在することを確認します。
- ディレクトリマネージャのパスワードを確認します。
- libdigest-plugin.ldif ファイルを編集します。すべての参照を、/path/to からダイジェストプラグイン共有ライブラリがインストールされている場所に変更します。
- 次のコマンドを実行して、プラグインをインストールします。
% ldapmodify -D "cn=Directory Manager" -w password -a < libdigest-plugin.ldif
Windows 環境でのダイジェスト認証
ダイジェスト認証プラグインを Windows 環境にインストールするには、次の手順を実行します。
注 Sun ONE Directory Server がダイジェストプラグインを正しく認識して起動するように、Sun ONE Application Server のいくつかの .dll ファイルを Sun ONE Directory Server のマシンにコピーする必要があります。
- Sun ONE Application Server の共有ライブラリが格納されている次の場所にアクセスします。
install_dir¥bin
- 次のファイルをコピーします。
- 次のいずれかの場所にファイルを貼り付けます。
DES アルゴリズムの使用に関する Sun ONE Directory Server の設定
ダイジェストパスワードが記録された属性を暗号化するには、DES アルゴリズムが必要です。DES アルゴリズムを使用するように Sun ONE Directory Server を設定するには、次の手順を実行します。
- Sun ONE Directory Server コンソールを起動します。
- Sun ONE Directory Server のインスタンスを開きます。
- 「設定」タブを選択します。
- プラグインのとなりの「+」記号をクリックします。
- DES プラグインを選択します。
- 新しい属性を追加するには、「追加」をクリックします。
- iplanetReversiblePassword と入力します。
- 「保存」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
.
注 ユーザーの iplanetReversiblePassword 属性にダイジェスト認証パスワードを設定するには、エントリに iplanetReversiblePasswordobject オブジェクトが指定されている必要があります。
ホスト - IP 認証の実装
1 台のコンピュータを複数で使用することもあるため、ホスト - IP 認証とユーザー - グループ認証を組み合わせると効果的です。ユーザー - グループ認証とホスト - IP 認証の両方を利用した場合は、アクセス時にユーザー名とパスワードが必要となります。
ホスト - IP 認証では、Sun ONE Application Server に DNS を設定する必要はありませんが、ネットワーク上で DNS を稼働させ、Sun ONE Application Server がそれを使用できるように設定する必要があります。
注 DNS を有効にするときは、管理インタフェースから HTTP サーバーの「調整」ページにアクセスします。
DNS を有効にすると、Sun ONE Application Server が DNS ルックアップを行うため、サーバーのパフォーマンスは低下します。DNS ルックアップが Sun ONE Application Server のパフォーマンスに与える影響を少なくするには、すべての要求で IP アドレスを解決する代わりに、アクセス制御と CGI の IP アドレスだけを解決します。DNS の影響を最小限に抑えるには、obg.conf ファイルの AddLog fn="flex-log" name="access" に iponly=1 を追加します。
AddLog fn="flex-log" name="access" iponly=1
ACL ファイルの操作
中心的な ACL ファイルの名前は generated.server-id.acl で、一時作業ファイルの名前は genwork.server-id.acl です。管理サーバーを使ってアクセスを設定する場合、この 2 つのファイルが存在します。ただし、より複雑な制限を設けるときは複数のファイルを作成し、それを server.xml ファイルから参照させます。また、時間帯や曜日によってサーバーへのアクセスを制限する場合など、ファイルの編集が必要な機能もあります。
アクセス制御ファイルは、instance_dir/config ディレクトリに保存されています (instance_dir はインスタンス名)。たとえば、最初のサーバーインスタンスのアクセス制御ファイルは install_dir/domains/domain1/server1/config ディレクトリに保存されます。
この節では次のトピックについて説明します。
ACL ファイルの構文
ACL ファイルは、特定の書式と構文で記述する必要があります。ACL リストに含まれる通常の ACL 定義は、タイプ、認証方法、承認方法に関する多数のステートメントから構成されます。
次に示すのはACL ファイルの一部です。
version 3.0;
# The "default" rules apply to the entire document
acl "default";
authenticate (user,group) {
database = "default";
method = "basic";
};
deny (all)
user = "anyone");
allow (read,execute,list,info)
(user = "all");
};この例に含まれるコンポーネントは次のとおりです。
- バージョン行 - すべての ACL ファイルは、バージョン番号を示す行から始まる。ACL ファイルのバージョン行は 1 つだけである。たとえば、次のように記述する
version 3.0;
- タイプステートメント - 定義する ACL のタイプを指定する。たとえば、次のように記述する
acl "default";
- 認証ステートメント - 認証方法を指定する (省略可能)。たとえば、次のように記述する
authenticate (user,group) {
database = "default";
method = "basic";
- 承認ステートメント - サーバーリソースへのアクセスを誰に許可するか、または拒否するかを指定する。たとえば、次のように記述する
deny (all)
(user = "anyone");
allow (read,execute,list,info)
(user = "all");文字列には、次の文字を使用できます。
- a 〜 z のアルファベット
- 0 〜 9 の数字
- ピリオド (.) とアンダースコア (_)
その他の文字を使うときは、その文字を二重引用符 (") で囲む必要があります。
- 1 つのステートメントは 1 行で記述し、セミコロン (;) で終了する
- 複数のステートメントは中カッコ ({ }) で囲む
- 項目のリストでは、項目をコンマで区切り、リスト全体を二重引用符 (") で囲む
タイプステートメント
ファイル内の各 ACL 定義には、ACL のタイプを示すステートメントが含まれます。次のいずれかのタイプを指定します。
- パス ACL - 関連するリソースの絶対パスを指定する
- URI (Uniform Resource Indicator) ACL - サーバーのドキュメントルートに基づいてディレクトリまたはファイルを指定する
- 命名済み ACL - obj.conf ファイル内のリソースで参照される名前を指定する。サーバーのデフォルトの命名済みリソースは、全員に読み込みアクセスを許可し、LDAP ディレクトリに記録されているユーザーに書き込みアクセスを許可する。Sun ONE Application Server を使って命名済み ACL を作成した場合は、obj.conf ファイル内のリソースがその ACL を参照するように編集する必要がある
タイプステートメントは、acl という文字列から始まり、二重引用符で囲まれたタイプ情報が続き、セミコロンで終了します。各 ACL のタイプ情報は、すべての ACL ファイルを通じて一意である必要があります。次に、タイプがそれぞれ異なる ACL の例を示します。
acl "path=C:/Sun/Servers/docs/mydocs/";
acl "default";
acl "uri=/mydocs/";パス ACL と URI ACL では、エントリの最後にワイルドカードを使えます。たとえば、/a/b/* のように記述します。ワイルドカードをエントリの最後以外の場所に記述しても機能しません。
認証ステートメント
Sun ONE Application Server が ACL を処理するときに適用される認証方法を必要に応じて ACL に指定することができます。一般的な認証方法は、次の 3 種類です。
- 基本認証 (デフォルト) - リソースにアクセスする前に、ユーザー名とパスワードを入力する必要がある
ACL に認証方法が指定されていない場合、デフォルトでは Sun ONE Application Server はこの基本認証を適用する
- SSL 認証 - ユーザーはクライアント証明書を必要とする。Sun ONE Application Server 側で暗号化を有効にし、ユーザー証明書の発行者が信頼できる CA のリストに登録されている必要がある
- ダイジェスト認証 - リソースにアクセスする前に、ユーザー名とパスワードを入力する必要がある
注 この場合、ユーザーが送信するダイジェスト認証を Sun ONE Application Server 認証データベースが処理できる必要があります。
各認証ステートメントには、Sun ONE Application Server がどの属性 (ユーザー、グループ、または両方) を認証するかを指定します。
例
データベースまたはディレクトリに記録されている情報と一致するユーザーの基本認証を指定する場合
authenticate (user) {
method = "basic";
};ユーザー - グループの SSL 認証方法を指定する場合
authenticate (user, group) {
method = "ssl";
};ユーザー名が sales から始まるすべてのユーザーにアクセスを許可する場合
authenticate (user) {
allow (all)
user = sales*
};
認証対象を指定する行で user が指定され、group が指定されていないため、最後の行を group=sales に変更すると ACL は失敗します。
承認ステートメント
承認ステートメントは、サーバーリソースへのアクセスを誰に許可するか、または拒否するかを指定します。各 ACL エントリには、1 つまたは複数の承認ステートメントを記述することができます。承認ステートメントの構文は次のとおりです。
allow|deny [absolute] (right[,right...]) attribute expression;
それぞれの行は、allow または deny というキーワードから始まります。
規則は階層構造なので、最上位レベルの規則では全員のアクセスを拒否し、ユーザー、グループ、またはコンピュータからのアクセスを下位レベルの規則で許可することをお勧めします。
シナリオ
/my_stuff というディレクトリに対して全員がすべてのアクセス権を持つ場合に、 /my_stuff/personal というサブディレクトリへのアクセス権を一部のユーザーにだけ限定することはできません。これは、/my_stuff ディレクトリにアクセスできるユーザーは、全員が /my_stuff/personal ディレクトリへのアクセスを許可されるためです。これを回避するには、まず全員のアクセスを拒否する /my_stuff/personal という規則を作成し、その後でアクセスを許可するユーザーを指定します。
注 デフォルトの ACL で全員のアクセスを拒否した場合は、その他の ACL 規則では全員のアクセスを拒否する規則が不要な場合があります。
次の承認ステートメントは、全員のアクセスを拒否します。
deny (all)
user = "anyone";次の各項では、承認ステートメントの詳細について説明します。
承認ステートメントの階層
ACL には、リソースに基づく階層があります。たとえば、Sun ONE Application Server がドキュメント (URI) の要求として /my_stuff/web/presentation.html を受け取ると、サーバーはこの URI に適用される ACL のリストを作成します。
- Sun ONE Application Server は、まずサーバーの obj.conf ファイルにある check-acl ステートメントに記録されている ACL を追加する
- 次に、サーバーは一致する URI ACL と PATH ACL を追加する
絶対 ACL ステートメントが指定されていない限り、すべてのステートメントが順に評価されます。絶対 allow ステートメントまたは絶対 deny ステートメントの評価結果が真であれば、サーバーは処理を停止し、アクセスを許可、または拒否します。
複数の ACL と一致する場合は、Sun ONE Application Server は最後に一致したステートメントを適用します。ただし、絶対ステートメントを使った場合は、サーバーは検索を中止し、絶対ステートメントを含む ACL を適用します。同じリソースに対して 2 つの絶対ステートメントを作成した場合は、Sun ONE Application Server は最初に見つかったステートメントを使い、その他の一致するリソースの検索を中止します。
次の例では、"joe" という名前のユーザーが他にいたとしても、絶対ステートメントによって "joe" が見つかった時点で検索を中止します。
version 3.0;
acl "default";
authenticate (user,group) {
prompt="Sun ONE Application Server";
};
allow (read,execute,list,info)
user = "anyone";
allow (write,delete)
user = "all";
acl "uri=/my_stuff/web/presentation.html";
deny (all)
user = "anyone";
allow (all)
user = "joe";属性式
属性式は、ユーザー名、グループ名、ホスト名、または IP アドレスに基づいて、アクセスを許可または拒否する対象を定義します。次の例は、異なるユーザー、またはコンピューターにアクセス権を指定する方法を示しています。
user = "anyone"
user = "smith*"
group = "sales"
dns = "*.sun.com"
dns = "*.sun.com,*.mozilla.com"
ip = "198.*"
ciphers = "rc4"
ssl = "on"
timeofday = <0800 or timeofday=1700
dayofweek = "Sat,Sun"
timeofday 属性を使って、時間帯 (サーバーのローカル時間で指定) に応じてサーバーへのアクセスを制限することもできます。詳細については、「時間帯によるアクセスの制限」を参照してください。
timeofday 属性を使えば、たとえば、特定ユーザーのアクセスを特定の時間帯に制限することができます。
注 時刻を指定するときは、24時間方式で指定します。たとえば、午前 4 時は 0400 と表記し、午後 10 時 30 分は 2230 と表記します。
例
guests という名前のユーザーグループのアクセスを午前 8 時から午後 4 時 59 分までに制限する場合
allow (read
(group="guests") and
(timeofday<0800 or timeofday=1700);dayofweek 属性に曜日を表す 3 文字の略語 (Sun、Mon、Tue、Wed、Thu、Fri、Sat) を指定することで、曜日単位でアクセスを制限することもできます。
例
premium グループのユーザーには曜日に関係なく終日のアクセスを許可し、discount グループのユーザーには週末だけ終日アクセスを許可し、平日は午前 8 時から午後 4 時 59 分までのアクセスを拒否する場合
allow (read)
(group="discount" and dayofweek="Sat,Sun") or
(group="discount" and (dayofweek="mon,tue,wed,thu,fri" and
(timeofday<0800 or timeofday=1700)))
または
(group="premium");演算子
属性式にはさまざまな演算子を使えます。カッコ ( ) は、演算子の適用優先度を示しています。ユーザー、グループ、DNS、および IP アドレスの指定では、次の演算子を使えます。
- and
- or
- not
- = (等価)
- != (等価ではない)
timeofday 属性と dayofweek 属性では、次の演算子を使えます。
- > (より大きい)
- < (より小さい)
- >= (以上)
- <= (以下)
ACL ファイルの例
次の ACL ファイルの例には、管理サーバー (admin-server) の 2 つのデフォルトエントリと、admin-reduced グループに管理サーバーへのアクセスを許可する追加エントリが含まれています。
例
ユーザーが http://server_name/my_stuff/web/presentation.html を要求すると、Sun ONE Application Server はまず、サーバー全体のアクセス制御を確認します。サーバー全体の ACL に継続が設定されていれば、サーバーは my_stuff ディレクトリの ACL を確認します。ACL が存在する場合、サーバーはその ACL に含まれる ACE を確認し、次のディレクトリに移動します。このプロセスは、アクセスを拒否する ACL が見つかるか、要求された URL の最後の ACL (この例では presentation.html ファイル) に到達するまで続けられます。
ACL 式のカスタマイズ
ACL の式をカスタマイズすることができます。一部の機能は、ACL ファイルを編集するか、カスタマイズされた式を作成しなければ利用できません。たとえば、サーバーへのアクセスを時間帯や曜日で制限する場合などです。
注 このオプションを利用するには、ACL ファイルの構文と構造を十分に理解している必要があります。
次のカスタム式は、日時と曜日によってアクセスを制限する方法を示しています。この例では、LDAP ディレクトリで regular グループと critical グループの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)
}クライアント認証の設定
注 証明書の有効期限切れ - 証明書の有効期限が切れると、Sun ONE Application Server はエラーを記録して証明書を拒否し、クライアントにメッセージを返します。どの証明書の有効期限が切れているかは、管理サーバーの「証明書の管理」ページで確認できます。
管理サーバーまたはサーバーインスタンスのクライアント認証を設定できます。次の各項では、その方法について説明します。
管理サーバーのクライアント認証の設定
管理サーバーレベルでクライアント認証を設定する手順は、次のとおりです。
- 管理サーバーにアクセスし、右のペインの「HTTP リスナー」タブを選択します。
管理サーバーの「HTTP リスナー」ページが表示されます。
管理サーバーの「HTTP リスナー」ページ
- 「SSL/TLS を有効」をクリックしてセキュリティを有効にします (デフォルトは無効)。
- 「クライアント認証を有効」をクリックして、クライアント認証を有効にします (デフォルトは無効)。
- 「保存」をクリックします。
- 右のペインの「コントロール」タブを選択し、「変更の適用」をクリックします。
管理サーバーの「コントロール」ページ
- サーバーを停止し、再起動して変更を適用します。
管理サーバーを起動するには、install_dir/domains/domain1/admin-server/bin/startserv にアクセスします。
サーバーインスタンスのクライアント認証の設定
サーバーインスタンスレベルでクライアント認証を設定する手順は、次のとおりです。
- 「アプリケーションサーバーインスタンス」にアクセスし、左のペインでサーバーインスタンスを選択します。
- 左のペインで「HTTP サーバー」を展開し、「HTTP リスナー」をクリックします。
「HTTP リスナー」ページにリスナーインスタンスが一覧表示されます。
- インスタンスを選択します。
そのインスタンスの「HTTP リスナー」ページが表示されます。
管理サーバーインスタンスの「HTTP リスナー」ページ
- 「SSL/TLS を有効」チェックボックスをクリックしてセキュリティを有効にします (デフォルトは無効)。
- 「クライアント認証を有効」チェックボックスをクリックして、クライアント認証を有効にします (デフォルトは無効)。
- 「保存」をクリックします。
- 左ペインで「アプリケーションサーバーインスタンス」を選択して自分のサーバーインスタンスにアクセスし、「変更の適用」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
.
certmap.conf ファイルの操作
証明書のマッピングは、サーバーが LDAP ディレクトリからユーザーエントリを検索するメカニズムです。certmap.conf ファイルを使うことで、名前で指定した証明書を LDAP エントリにどのようにマッピングするかを設定できます。このファイルを編集して LDAP の構成と一致するエントリを追加したり、ユーザーに持たせる証明書の一覧を表示したりします。ユーザー ID、電子メールアドレス、または subjectDN に記録されているその他の値に基づいてユーザーを認証できます。具体的には、マッピングファイルには次の情報が記録されています。
- サーバーが、LDAP ツリーのどこから検索を開始するか
- LDAP ディレクトリからエントリを検索するときに、サーバーが検索条件として使用する証明書属性
- サーバーが別の検証プロセスに進むかどうか
証明書マッピングファイルは、次の場所に保存されます。
/instance_dir/config/certmap.conf
ファイルには、名前がつけられた 1 つまたは複数のマッピングが含まれ、それぞれが異なる CA に適用されます。マッピングの構文は次のとおりです。
certmap <name> <issuerDN>
<name>:<property> [<value>]最初の行は、エントリの名前、および CA 証明書に含まれる DN を構成する属性を指定しています。エントリには任意の名前を定義できます。ただし issuerDN は、クライアント証明書を発行した CA の発行者 DN と完全に一致している必要があります。たとえば、次の 2 行の issuerDN は、属性の区切りに含まれる空白文字の有無だけが異なりますが、サーバーは 2 つの異なるエントリとして認識します。
次の各項では、certmap.conf ファイルについて説明します。
デフォルトプロパティ
名前がつけられたマッピングの 2 行目以降の行は、プロパティとその値です。certmap.conf には、6 つのデフォルトプロパティがあります。証明書 API を使って独自のプロパティを設定することもできます。
- DNComps - コンマで区切られた属性のリスト。ユーザー (クライアント証明書の所有者) の情報と一致するエントリの検索を Sun ONE Application Server がどの LDAP ディレクトリから開始するかを決定する。サーバーは、クライアント証明書からこれらの属性の値を収集し、LDAP DN に含まれる値を使用して、LDAP ディレクトリ内のどの場所から検索を開始するかを決定する。たとえば、DN の o 属性と c 属性を使用するように DNComps を設定すると、サーバーは LDAP ディレクトリ内の o=<org>、c=<country> エントリから検索を開始し、<org> と <country> は、証明書の DN に含まれる値に置き換えられる
状況によって処理は異なる
マッピングに DNComps エントリが含まれない場合、サーバーは CmapLdapAttr の設定、またはクライアント証明書 (ユーザー情報) に含まれる対象 DN 全体を使う
DNComps エントリは含まれるが、値が指定されていない場合、サーバーは LDAP ツリー全体でフィルタに一致するエントリを検索する
- FilterComps - コンマで区切られた属性のリスト。クライアント証明書に含まれるユーザーの DN から情報を収集してフィルタを作成する。サーバーは、これらの属性の値に基づいて、LDAP ディレクトリでのエントリの検索に適用する検索条件を決定する。証明書から収集したユーザー情報と一致するエントリが LDAP ディレクトリに 1 つまたは複数見つかると、検索は成功し、設定されている場合は検証が行われる
たとえば、電子メールアドレス属性とユーザー ID 属性を使うように FilterComps を設定すると (FilterComps=e,uid)、サーバーは、電子メールアドレスとユーザー ID の値がクライアント証明書から収集したユーザー情報と一致するエントリをディレクトリから検索する。電子メールアドレスとユーザー ID は、ディレクトリ内で一意の情報であるため、フィルタとして適している。フィルタは、LDAP データベース内のエントリを 1 つだけに絞り込める程度に具体的である必要がある。
次の表は、x509v3 証明書の属性を示している
x509v3 証明書の属性
属性
説明
c
国名
o
組織名
cn
共通名
l
場所
st
州
ou
部署名
uid
UNIX ユーザー ID
電子メールアドレス
注 フィルタの属性名は、LDAP ディレクトリ側の属性名ではなく、証明書側の属性名を使用する必要があります。たとえば、一部の証明書の e 属性はユーザーの電子メールアドレスを意味しますが、LDAP ではこの属性は mail で表されます。
- verifycert - クライアント証明書と LDAP ディレクトリに格納されている証明書を比較するかどうかを決定する。on、off の 2 つの値をとる。このプロパティは、LDAP ディレクトリに証明書が格納されている場合にだけ使用する。ユーザーの証明書が有効であることを確認する場合に便利な機能である
- CmapLdapAttr - ユーザーが所属するすべての証明書から収集した対象 DN を含む、LDAP ディレクトリ内の属性名。このプロパティのデフォルト値は certSubjectDN である。この属性は標準の LDAP 属性ではないため、このプロパティを使用する場合は LDAP スキーマを拡張する必要がある。
certmap.conf ファイルにこのプロパティが指定されている場合、サーバーは、証明書に含まれる対象の完全 DN と一致する属性 (このプロパティによって指定される属性) を持つエントリを LDAP ディレクトリ全体から検索する。エントリが見つからない場合は、サーバーは DNComps と FilterComps のマッピングを使って再検索を行う。
証明書のエントリと LDAP エントリとの一致で検索するこの方法は、DNComps および FilterComps によるエントリの検索が困難な場合に便利である
- Library - 共有ライブラリまたは DLL のパスを値に持つプロパティ。このプロパティは、証明書 API を使って独自のプロパティを作成した場合にだけ使用する。詳細は、『Sun ONE Application Server Developer's Guide to NSAPI』を参照
- InitFn - カスタムライブラリの init 関数の名前を値に持つプロパティ。このプロパティは、証明書 API を使って独自のプロパティを作成した場合にだけ使用する
これらのプロパティの詳細については、で説明する例を参照してください。
カスタムプロパティの作成
クライアント証明書 API を使って、独自のプロパティを作成できます。プログラミングの詳細とクライアント証明書 API の使用方法については、『Sun ONE Application Server Developer's Guide to NSAPI』を参照してください。
カスタムマッピングを作成したら、次のようにマッピングを参照します。
<name>:library <path_to_shared_library>
<name>:InitFn <name_of_init_function次に例を示します。
certmap default1 o=Netscape Communications, c=US
default1:library /usr/netscape/enterprise/auth-db/plugin.so
default1:InitFn plugin_init_fn
default1:DNComps ou o c
default1:FilterComps l
default1:verifycert onマッピングの例
certmap.conf ファイルには、少なくとも 1 つのエントリが必要です。次の例は、certmap.conf ファイルのさまざまな使用方法を示しています。
例 1
この例は、1 つのデフォルトマッピングだけを持つ certmap.conf を示しています。
certmap default default
default:DNComps ou, o, c
default:FilterComps e, uid
default:verifycert onこの例を使うと、ou=<orgunit>、o=<org>、c=<country> というエントリを含む LDAP 分岐ポイントから検索が開始されます。<> で囲まれたテキストは、クライアント証明書の対象 DN に含まれる値に置き換えられます。
次に、サーバーは証明書の電子メールアドレスとユーザー ID の値を使って LDAP ディレクトリで一致するエントリを検索します。エントリが見つかると、サーバーはクライアントから送信された証明書とディレクトリに格納されている証明書を比較して検証します。
例 2
この例には 2 つのマッピングが含まれます。一方はデフォルトで、もう一方は US Postal Service のマッピングです。
certmap default default
default:DNComps
default:FilterComps e, uidcertmap usps ou=United States Postal Service, o=usps, c=US
usps:DNComps ou,o,c
usps:FilterComps e
usps:verifycert onUS Postal Service 以外の証明書を受け取った場合はデフォルトのマッピングが使用され、クライアントの電子メールアドレスとユーザー ID と一致するエントリの検索が LDAP ツリーの最上部から開始されます。US Postal Service の証明書を受け取った場合は、電子メールアドレスが一致するエントリの検索が部署名を含む LDAP の分岐から開始されます。US Postal Service からの証明書の場合、サーバーは証明書を検証しますが、それ以外の証明書の検証は行われません。
警告
証明書に含まれる発行者 DN (CA の情報) は、マッピングの最初の行に記録された発行者 DN と一致する必要があります。前述の例では、証明書に含まれる発行者 DN が o=United States Postal Service,c=US の場合、o 属性と c 属性の間に空白文字が含まれないため一致しません。
例 3
次の例は、CmapLdapAttr プロパティを使って、certSubjectDN という属性がクライアント証明書の対象 DN 全体と完全に一致するエントリを LDAP データベースから検索します。
certmap myco ou=My Company Inc, o=myco, c=US
myco:CmapLdapAttr certSubjectDN
myco:DNComps o, c
myco:FilterComps mail, uid
myco:verifycert onクライアント証明書の対象 DN が次のようになっているとします。
uid=Walt Whitman, o=LeavesOfGrass Inc, c=US
サーバーはまず、次の情報を含むエントリを検索します。
certSubjectDN=uid=Walt Whitman, o=LeavesOfGrass Inc, c=US
複数のエントリが検索された場合、サーバーはエントリの検証を開始します。エントリが見つからなかった場合、サーバーは DNComps と FilterComps を使って一致するエントリを検索します。
この例では、サーバーは o=LeavesOfGrass Inc, c=US の下のすべてのエントリから uid=Walt Whitman と一致するエントリを検索します。
注 この例は、certSubjectDN 属性が設定されたエントリが LDAP ディレクトリに含まれていることを前提としています。
ACL/ACE の設定
この節では次のトピックについて説明します。
許可または拒否の設定
要求がアクセス制御の規則と一致したときにサーバーが実行する処理を指定できます。
- 許可 - ユーザーまたはシステムは必要なリソースにアクセスできる
- 拒否 - ユーザーまたはシステムはリソースにアクセスできない
サーバーは、ACE のリストを調べてアクセス権の有無を決定します。たとえば、通常は最初の ACE は全員のアクセスを拒否します。継続が設定されていない場合は、リソースに対する全員のアクセスが拒否されます。
最初の ACE に継続が設定されている場合、サーバーはリストの 2 番目の ACE を調べ、それが一致する場合は次の ACE を調べます。サーバーは、一致しない ACE を見つけるまで、または一致はするが継続が設定されていない ACE を見つけるまでリストの順に ACE を調べます。最後に一致した ACE がアクセスの許可または拒否を決定します。
ユーザー - グループ認証の設定
ユーザー - グループ認証では、アクセス制御規則に指定されているリソースにアクセスするときに、ユーザーはユーザー名とパスワードを入力します。Sun ONE Application Server は、LDAP サーバーに記録されているユーザーとグループのリストを検索します。
データベースに記録されている全員のアクセスを許可または拒否する、ワイルドカードのパターンを使って特定のユーザーのアクセスを許可または拒否する、またはユーザーとグループのリストを使って選択したユーザーのアクセスを許可または拒否することができます。
- 全員(デフォルト) - 認証を必要としない。ユーザー名またはパスワードを入力せずに、全員がリソースにアクセスできる。ただし、ホスト名や IP アドレスなど、その他の設定によってアクセスが拒否される可能性はある
- 認証された人のみ
認証データベース中のすべて - データベースにエントリが存在するすべてのユーザーのアクセスを許可する
指定のユーザーのみ - 指定のユーザーおよびグループと一致するユーザーのアクセスを許可する。コンマでエントリを区切って、またはワイルドカードのパターンを使ってユーザーまたはユーザーグループのリストを作成できる。また、データベースに格納されているユーザーおよびグループのリストを選択することもできる。グループの一致では、そのグループに含まれるすべてのユーザーが対象となる。ユーザーの一致では、指定したユーザーだけが対象となる
- 認証プロンプト - 認証ダイアログボックスに表示されるメッセージテキストを入力できる。このテキストに入力が必要な内容を説明する。オペレーティングシステムによっては、最初の 40 文字だけが表示される。ユーザー名とパスワードは、プロンプトテキストと関連づけられる。ユーザーが同じプロンプトのサーバーにあるファイルやディレクトリにアクセスする場合は、ユーザー名とパスワードを入力し直す必要がない。特定のファイルまたはディレクトリへのアクセスでユーザー認証を再実行する場合は、そのリソースの ACL でプロンプトを変更する
- 認証方法 - サーバーがクライアントから認証情報を取得する方法を指定する。obj.conf ファイルに指定した方式が使われる。方式が obj.conf ファイルに指定されていない場合は、基本認証が使用される
基本 (デフォルト) - クライアントから認証情報を取得する HTTP メソッドを使用する。Sun ONE Application Server で暗号化を有効にした場合だけ、ユーザー名とパスワードが暗号化される。詳細については、「基本認証」を参照
注 管理サーバーで利用できるのは、基本認証だけです。
SSL - ユーザーの認証にクライアント証明書を必要とする。この方法を利用するには、Sun ONE Application Server で SSL を有効にする必要がある。暗号化を有効にしている場合は、基本認証と SSL 認証を組み合わせて利用できる。詳細については、「SSL 認証」を参照
ダイジェスト - ユーザー名とパスワードを通常テキストとして送信せずに、ユーザー名とパスワードを使用する。ブラウザは、MD5 アルゴリズムを使って、ユーザーのパスワードなどの情報からダイジェスト値を作成する。詳細は、「ダイジェスト認証」および「ホスト - IP 認証の実装」を参照
- 認証データベース - ユーザーの認証に Sun ONE Application Server が使用するデータベースを選択できる。デフォルトデータベースを選択した場合は、サーバーは LDAP ディレクトリからユーザーまたはグループを検索する
個々の ACL が異なるデータベースを使用するように設定するときは、「その他」を選択し、ドロップダウンリストからデータベースを選択する。この場合、デフォルト以外のデータベースと LDAP ディレクトリを instance_dir/config/dbswitch.conf ファイルに指定しておく必要がある。
アクセスを許可するホストの指定
要求の送信元コンピュータに基づいて、管理サーバーまたは Web サイトへのアクセスを制限することができます。
- どこからでも (Anyplace) - すべてのユーザーおよびシステムからのアクセスを許可する
- 次のホストからのみ (Only from) - 特定のホスト名または IP アドレスからのアクセスを制限できる
後者のオプションを選択した場合は、ワイルドカードのパターンを使用して、またはコンマで区切ってアクセスを許可するエントリを「ホスト名」フィールドまたは「IP アドレス」フィールドに入力します。ユーザーが IP アドレスを変更した場合にリストを更新する必要がないので、IP アドレスよりも、ホスト名を指定したほうが制限を柔軟にできます。ただし、接続クライアントの DNS ルックアップに失敗するとホスト名による制限を使えなくなるため、IP アドレスを指定したほうが信頼性は高くなります。
コンピュータのホスト名または IP アドレスの一致を検索するためのワイルドカードのパターンに使える文字は * だけです。たとえば、特定のドメインのすべてのコンピュータからのアクセスを許可または拒否するときは、*.sun.com のように、そのドメインのすべてのホストと一致させるワイルドカードパターンを入力します。管理サーバーにアクセスするスーパーユーザーには、別のホスト名と IP アドレスを設定できます。
詳細は、「ホスト - IP 認証の実装」を参照してください。
アクセス権限の設定
アクセス権限は、Web サイト上のファイルやディレクトリへのアクセスを制限します。すべてのアクセス権限を許可または拒否するだけでなく、規則を指定して一部のアクセス権限だけを許可または拒否することもできます。たとえば、ユーザーにファイルの読み込みアクセス権限だけを設定して書き込みアクセスを拒否することで、そのユーザーは情報を表示できても、ファイルの内容を変更できなくなります。
- すべてのアクセス権限 (デフォルト) - すべてのアクセス権限を許可または拒否する
- 次の権利のみ - 特定の権限の組み合わせを選択し、その権限だけを許可または拒否できる
読み込み - ユーザーにファイルの表示を許可する。GET、HEAD、POST、INDEX の HTTP メソッドを含む
書き込み - ユーザーにファイルの変更と削除を許可する。PUT、DELETE、MKDIR、RMDIR、MOVE の HTTP メソッドを含む。ファイルを削除するには、ユーザーは書き込みと削除の両方のアクセス権限が必要となる
実行 - ユーザーに CGI プログラム、Java アプレット、エージェントなどのサーバー側アプリケーションの実行を許可する
削除 - 書き込みアクセス権限を持つユーザーにファイルまたはディレクトリの削除を許可する
リスト - INDEX メソッドによるディレクトリ内のファイルリストへのアクセスをユーザーに許可する
情報 - HEAD など、URI に関する情報の取得をユーザーに許可する
obj.conf ファイル内の ACL ファイルの参照
ACL を指定する、または独立した ACL ファイルを作成すると、それを obj.conf ファイルで参照させることができます。これは、check-acl 関数を使って、PathCheck 指令に指定されます。この行の構文は次のとおりです。
PathCheck fn="check-acl" acl="aclname"
aclname は、すべての ACL ファイルを通じて一意の ACL 名です。
たとえば、testacl という ACL を使ってディレクトリへのアクセスを制限するときは、obj.conf ファイルに次の行を追加します。
<Object ppath="/usr/ns-home/docs/test/*"
PathCheck fn="check-acl" acl="testacl"
</Objectこの例の 1 行目は、アクセス制限の対象となるサーバーリソースを指定するオブジェクトです。2 行目は、PathCheck 指令です。この指令は、check-acl 関数を使って、ACL 名 (testacl) と指令が実行されるオブジェクトをバインドします。
testacl ACL は、init.conf ファイルで参照されるどの ACL ファイルにも記述できます。
ACL ユーザーキャッシュの設定
デフォルトでは、Sun ONE Application Server はユーザーとグループの認証結果を ACL ユーザーキャッシュにキャッシュします。この節では、init.conf ファイルに含まれる ACL ユーザーキャッシュ指令について説明します。
ACLCacheLifetime
ACLCacheLifetime は、キャッシュエントリが無効になるまでの時間を秒数で指定します。キャッシュのエントリが参照されるたびに、経過時間が計算され ACLCacheLifetime と照合されます。経過時間が ACLCacheLifetime に指定された値に達するか超過した場合、このエントリは使用されません。この値を 0 にすると、キャッシュが無効になります。
この値を大きくすると、LDAP エントリを変更した場合に Sun ONE Application Server の再起動が必要になることがあります。たとえば 120 秒に設定すると、Sun ONE Application Server は 2 分間 LDAP サーバーと同期が取れなくなる可能性があります。LDAP が頻繁に変更されない場合は、大きな値を設定できます。デフォルト値は 120 です。
ACLUserCacheSize
ACLUserCacheSize は、ユーザーキャッシュのユーザー数を指定します。新しいエントリはリストの先頭に追加され、キャッシュが最大サイズに達すると、リストの最後のエントリが新しいエントリを作成するために再利用されます。
デフォルト値は 200 です。
ACLGroupCacheSize
ACLGroupCacheSize は、1 つの UID/キャッシュエントリに対してキャッシュできるグループ ID の数を指定します。残念ながら、ユーザーがグループに含まれないという情報はキャッシュされないため、要求のたびに LDAP ディレクトリへのアクセスが数回発生します。デフォルト値は 4 です。
ACL ファイル指令の詳細については、『Sun ONE Application Server 管理者用設定ファイルリファレンス』を参照してください。
サーバーインスタンスのアクセス制御の設定
特定のサーバーインスタンスのアクセス制御を作成、編集、削除することができます。
注 削除する場合、ACL ファイルからすべての ACL 規則を削除するべきではありません。サーバーを起動するには、少なくとも 1 つの ACL 規則を含む 1 つの ACL ファイルが必要です。すべての ACL 規則を削除してサーバーを再起動すると、構文エラーとなります。
サーバーインスタンスのアクセス制御を作成する手順は、次のとおりです。
- 「アプリケーションサーバーインスタンス」の「HTTP サーバー」にアクセスします。
- 「ACL」を選択します。
既存の ACL を表示した「ACL」ページが表示されます。
- 編集する ACL ファイルをクリックします。
「ACL ファイルを編集 (Edit ACL File)」ページが表示されます。
「ACL ファイル」ページ
- 「ACL ファイルを編集 (Edit ACL File)」ボタンをクリックします。
「アクセス制御リストを管理 (Access Control List Management)」ページが表示されます。
「アクセス制御リスト管理」ページ
- 次のいずれかを選択します。
リソースを選択 (Pick a resource) - アクセスを制限するファイルまたはディレクトリの名前を選択するか、ファイルまたはディレクトリを参照して、ファイルまたはディレクトリのワイルドカードパターン (*.html など) を指定する
既存の ACL を選択 (Pick an existing ACL) - 有効なすべての ACL のリストから ACL を選択する。有効になっていない既存の ACL はリストに表示されない
ACL名を入力 (Type in the ACL name) - ACL を名前で指定する
注 このオプションは、ACL ファイルについて十分に理解している場合にだけ使用してください。名前をつけた ACL をリソースに適用するときは、obj.conf ファイルを開いて編集する必要があります。
次の表は、リソースの指定に利用できるワイルドカードを示しています。左の列はリソースワイルドカードを示し、右の列ではその機能を説明しています。
- 「アクセス制御を編集 (Edit Access Control)」をクリックします。
「アクセス制御ルール (Access Control Rules for):」 (サーバーインスタンス) が表示されます。
アクセス制御規則
- 「アクセス制御はオン (Access Control is on)」にチェックマークがつけられていることを確認します。
- このサーバーインスタンスの ACL を作成または編集するときは、「アクション (Action)」列の「拒否 (Deny)」をクリックします。
- 選択されていない場合は「許可 (Allow)」を選択し、「更新 (Update)」をクリックします。
- 「ユーザー/グループ (User/Group)」列の「誰でも (Anyone)」をクリックします。
「ユーザー/グループ (User/Group)」ページが表示されます。
アクセス制御の「ユーザー/グループ」規則
- アクセスを許可するユーザーとグループを指定し、「更新 (Update)」をクリックします。
「ユーザーとグループのリスト」をクリックすると、ユーザーとグループがリスト表示されます。
- 「アクセスを許可するホスト (From Host)」列の「どこからでも (Anyplace)」をクリックします。
アクセス制御の「アクセスを許可するホスト」規則
- アクセスを許可するホストの名前と IP アドレスを入力し、「更新 (Update)」をクリックします。
- 「権限 (Rights)」列のすべての項目をクリックします。
アクセス制御の「権限」規則
- 次のいずれかをクリックし、「更新 (Update)」をクリックします。
- (省略可能) 「追加」列の「x」をクリックし、カスタマイズした ACL 式を追加します。
- 選択されていない場合は、「継続 (Continue)」列にチェックマークをつけます。
ユーザーにアクセスを許可するかどうかを決定する前に、サーバーは次の行を評価します。複数の行を作成することで、最も一般的な制限から限られたユーザーに限られた権限だけを許可する制限まで細かく指定できます。
- (省略可能) 「拒否された時に応答 (Response When denied)」をクリックします。
次のファイルで応答 (Respond with the following file): (リダイレクトはオフ)
次の URL、URI で応答 (Respond with the following URL or URI): (リダイレクトはオン)
- 絶対 URL または相対 URI を入力し、「更新 (Update)」をクリックします。
- 「送信 (Submit)」をクリックし、新しいアクセス制御規則を ACL ファイルに保存します。
注 「元に戻す (Revert)」をクリックすると、新たに設定した内容が元の設定に戻ります。
- アクセス制御を設定するサーバーインスタンスごとに、すべての手順を繰り返します。
- すべての作業が完了したら、「適用 (Apply)」をクリックします。
- 「了解 (OK)」をクリックします。
- 左ペインで「アプリケーションサーバーインスタンス (App Server Instances)」を選択して自分のサーバーインスタンスにアクセスし、「変更の適用 (Apply Changes)」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
ACL の設定は、仮想サーバーごとに有効と無効を指定できます。操作方法については、「仮想サーバー用のアクセス制御リストの編集」を参照してください。
サーバー内の領域へのアクセスの制限
「サーバーインスタンスのアクセス制御の設定」で説明した手順を完了すると、次のトピックで説明する方法で領域へのアクセス制限を追加できるようになります。
- サーバー全体へのアクセスの制限
- ディレクトリ (パス) に対するアクセスの制限
- URI (パス) に対するアクセスの制限
- ファイルタイプによるアクセスの制限
- 時間帯によるアクセスの制限
- セキュリティによるアクセスの制限
サーバー全体へのアクセスの制限
ネットワーク上の特定のサブドメインからサーバーにアクセスするユーザーグループのアクセスを制限することができます。
サーバー全体へのアクセスを制限するには、次の手順を実行します (サーバーインスタンスのアクセス制御の設定で説明した手順を使用)。
- 「アプリケーションサーバーインスタンス」の「HTTP サーバー」にアクセスします。
- 「ACL」を選択します。
「ACL」ページに既存の ACL が表示されます。
- 編集する ACL ファイルをクリックします。
- 「ACL ファイルを編集 (Edit ACL File)」ボタンをクリックします。
「アクセス制御リストを管理 (Access Control List Management)」ページが表示されます。
- サーバーリソース全体を選択し、「アクセス制御を編集 (Edit Access Control)」をクリックします。
- 全員のアクセスを拒否する新しい規則を追加します。
- 特定のグループにアクセスを許可する別の規則を新たに追加します。
- アクセスを許可するコンピュータのホスト名を指定するワイルドカードのパターンを入力します。
たとえば、*.employee.sun.com のように入力します。
- 「継続 (Continue)」のチェックマークを外します。
- 「送信 (Submit)」をクリックします。
- 左ペインで「アプリケーションサーバーインスタンス」を選択して自分のサーバーインスタンスにアクセスし、「変更の適用」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
ディレクトリ (パス) に対するアクセスの制限
ユーザーグループの所有者が制御するディレクトリ内のアプリケーションやサブディレクトリ、ファイルの読み込みと実行を、そのグループのユーザーに許可することができます。たとえば、プロジェクトマネージャが、プロジェクトの進捗状況を更新してプロジェクトチームのユーザーが参照できるようにすることができます。
サーバー上の特定のディレクトリへのアクセスを制限するには、次の手順を実行します (サーバーインスタンスのアクセス制御の設定で説明した手順を使用)。
- 「アプリケーションサーバーインスタンス」の「HTTP サーバー」にアクセスします。
- 「ACL」を選択します。
既存の ACL を表示した「ACL」ページが表示されます。
- 編集する ACL ファイルをクリックします。
- 「ACL ファイルを編集 (Edit ACL File)」ボタンをクリックします。
「アクセス制御リストを管理 (Access Control List Management)」ページが表示されます。
- アクセスを制限するディレクトリを「リソースを選択 (Pick a Resource)」から選択します。
サーバーのドキュメントルートに含まれるディレクトリが表示されます。選択すると、「編集 (Editing)」ドロップダウンリストにディレクトリの絶対パスが表示されます。
注 サーバールートのすべてのファイルを表示するときは、「オプション (Option)」をクリックし、「ディレクトリとファイルをリスト (List files as well as directories)」にチェックマークをつけます。
- 「アクセス制御を編集 (Edit Access Control)」をクリックします。
- アクセス元のコンピュータに関係なく全員のアクセスを拒否する新しい規則を作成します。
- 特定のグループに読み込み権限と実行権限だけを許可する別の規則を新たに作成します。
- 3 行目では、特定のユーザーにすべての権限を持たせます。
- 2 行目と 3 行目の「継続 (Continue)」を解除し、「更新 (Update)」をクリックします。
- 「送信 (Submit)」をクリックします。
- 左ペインで「アプリケーションサーバーインスタンス」を選択して自分のサーバーインスタンスにアクセスし、「変更の適用」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
ディレクトリまたはファイルへのパスが docroot ディレクトリに作成されます。ACL ファイルには、次のようなエントリが追加されます。acl "path=d:/Sun/suitespot/docroot1/sales/";
URI (パス) に対するアクセスの制限
URI を使って、サーバー上の一人のユーザーのコンテンツに対するアクセスを制御することができます。URI は、サーバーのドキュメントルートディレクトリに基づく相対的なパスとファイルです。URI を使うことで、サーバーのコンテンツのすべてまたは一部 (ディスクスペースなど) の名前を頻繁に変更する場合でも、コンテンツを簡単に管理できます。また、別のドキュメントルートがある場合にも簡単にアクセスを制御できます。
特定の URI へのアクセスを制限するには、次の手順を実行します (サーバーインスタンスのアクセス制御の設定で説明した手順を使用)。
- 「アプリケーションサーバーインスタンス」の「HTTP サーバー」にアクセスします。
- 「ACL」を選択します。
既存の ACL を表示した「ACL」ページが表示されます。
- 編集する ACL ファイルをクリックします。
- 「ACL ファイルを編集 (Edit ACL File)」ボタンをクリックします。
「アクセス制御リストを管理 (Access Control List Management)」ページが表示されます。
- アクセスを制限する URI を「ACL 名中のタイプ (Type in the ACL name)」に入力します。
たとえば、uri=/my_directory のように入力します。
- 「アクセス制御を編集 (Edit Access Control)」をクリックします。
- すべてのユーザーに読み込みアクセスを許可する新しい規則を作成します。
- ディレクトリの所有者にアクセスを許可する別の規則を新たに作成します。
- 1 行目と 2 行目の規則の「継続 (Continue)」を解除します。
- 「送信 (Submit)」をクリックします。
- 左ペインで「アプリケーションサーバーインスタンス」を選択して自分のサーバーインスタンスにアクセスし、「変更の適用」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
ドキュメントルートに基づく相対的な URI のパスが作成されます。ACL ファイルには、acl "uri=/my_directory"; のようなエントリが作成されます。
ファイルタイプによるアクセスの制限
サーバーまたは Web サイト上の特定のファイルタイプに対するアクセスを制限することができます。たとえば、サーバー上で実行するプログラムを作成する権限を、特定のユーザーだけに許可できます。誰もがプログラムを実行できますが、それを作成または削除できるのは、特定のユーザーグループだけです。
特定のファイルタイプへのアクセスを制限するには、次の手順を実行します (サーバーインスタンスのアクセス制御の設定で説明した手順を使用)。
- 「アプリケーションサーバーインスタンス」の「HTTP サーバー」にアクセスします。
- 「ACL」を選択します。
既存の ACL を表示した「ACL」ページが表示されます。
- 編集する ACL ファイルをクリックします。
- 「ACL ファイルを編集 (Edit ACL File)」ボタンをクリックします。
「アクセス制御リストを管理 (Access Control List Management)」ページが表示されます。
- 「リソースを選択 (Pick a Resource)」の「ワイルドカード (Wildcard)」をクリックし、ワイルドカードパターンを入力します。
たとえば、*.cgi のように入力します。
- 「アクセス制御を編集 (Edit Access Control)」をクリックします。
- すべてのユーザーに読み込みアクセスを許可する新しい規則を作成します。
- 特定のグループだけに書き込みと削除を許可する別の規則を新たに作成します。
- 「送信 (Submit)」をクリックします。
- 左ペインで「アプリケーションサーバーインスタンス」を選択して自分のサーバーインスタンスにアクセスし、「変更の適用」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
ファイルタイプによる制限では、どちらの「継続」ボックスもチェックしたままの状態で残します。ファイルに対する要求を受け取ると、サーバーはまず、そのファイルタイプの ACL を確認します。
obj.conf ファイルには Pathcheck 関数が作成されます。これは、ファイルまたはディレクトリを示すワイルドカードパターンを含んでいることがあります。ACL ファイルには、acl "*.cgi"; のようなエントリが作成されます。
時間帯によるアクセスの制限
特定の時間帯または曜日に、サーバーに対する書き込みおよび削除のアクセスを制限することができます。この制限は、ファイルへのアクセスが多い営業時間中にドキュメントの発行を防ぐ場合などに利用できます。
特定の時間帯でのアクセスを制限するときは、次の手順を実行します (サーバーインスタンスのアクセス制御の設定で説明した手順を使用)。
- 「アプリケーションサーバーインスタンス」の「HTTP サーバー」にアクセスします。
- 「ACL」を選択します。
「ACL」ページに既存の ACL が表示されます。
- 編集する ACL ファイルをクリックします。
- 「ACL ファイルを編集 (Edit ACL File)」ボタンをクリックします。
「アクセス制御リストを管理 (Access Control List Management)」ページが表示されます。
- 「リソースを選択 (Pick a Resource)」のドロップダウンリストからサーバー全体を選択し、「アクセス制御を編集 (Edit Access Control)」をクリックします。
- 全員に読み込みと実行を許可する新しい規則を作成します。
この規則を作成すると、ユーザーがファイルまたはディレクトリの追加、更新、削除が必要な場合に、この規則が適用されず、サーバーは要求と一致する別の規則を検索します。
- 全員の書き込みと削除を拒否する別の規則を新たに作成します。
- 「x」リンクをクリックして、式をカスタマイズします。
- アクセスを許可する曜日と時間帯を指定します。たとえば、次のように入力します。
user = "anyone" and
dayofweek = "sat,sun" or
(timeofday >= 1800 and
timeofday <= 600)
カスタマイズした式を作成すると、「ユーザー/グループ (Users/Groups)」フィールドと「アクセスを許可するホスト (From Host)」フィールドに「認識できない式 (Unrecognized Expressions)」というメッセージが表示されます。
- 「送信 (Submit)」をクリックします。
- 左ペインで「アプリケーションサーバーインスタンス」を選択して自分のサーバーインスタンスにアクセスし、「変更の適用」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
カスタマイズした式にエラーが含まれる場合は、エラーメッセージが表示されます。式を修正し、送信し直してください。
セキュリティによるアクセスの制限
同じサーバーインスタンスに SSL が有効な HTTP リスナーと SSL が無効なリスナーを設定できます。セキュリティに基づいてアクセスを制限することで、安全なチャンネルを通じて転送する必要のあるリソースを保護することができます。
セキュリティに基づいてアクセスを制限するには、次の手順を実行します (サーバーインスタンスのアクセス制御の設定で説明した手順を使用)。
- 「アプリケーションサーバーインスタンス」の「HTTP サーバー」にアクセスします。
- 「ACL」を選択します。
既存の ACL を表示した「ACL」ページが表示されます。
- 編集する ACL ファイルをクリックします。
- 「ACL ファイルを編集 (Edit ACL File)」ボタンをクリックします。
「アクセス制御リストを管理 (Access Control List Management)」ページが表示されます。
- 「リソースを選択 (Pick a Resource)」のドロップダウンリストからサーバー全体を選択し、「アクセス制御を編集 (Edit Access Control)」をクリックします。
- 全員に読み込みと実行を許可する新しい規則を作成します。
この規則を作成すると、ユーザーがファイルまたはディレクトリの追加、更新、削除が必要な場合に、この規則が適用されず、サーバーは要求と一致する別の規則を検索します。
- 全員の書き込みと削除を拒否する別の規則を新たに作成します。
- 「x」リンクをクリックして、式をカスタマイズします。
- ssl="on" と入力します。たとえば、次のように入力します。
user = "anyone" and ssl="on"
- 「送信 (Submit)」をクリックします。
- 左ペインで「アプリケーションサーバーインスタンス」を選択して自分のサーバーインスタンスにアクセスし、「変更の適用」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
カスタマイズした式にエラーが含まれる場合は、エラーメッセージが表示されます。式を修正し、送信し直してください。
アクセス制御の無効化
「アクセス制御はオン (Access Control is on)」というオプションのチェックマークを外すと、ACL の内容を削除することを確認するメッセージが表示されます。「了解 (OK)」をクリックすると、ACL ファイルに含まれる、そのリソースの ACL エントリが削除されます。
ACL を無効にするには、generated-server-id.acl ファイルに含まれる各 ACL 行の先頭に「#」記号を入力してコメントにします。
注 このアクセス制御は管理者グループのユーザーにだけ適用されます。管理サーバーは、まずユーザー (スーパーユーザーでない場合) が管理者グループに含まれるかどうかを確認し、その後でアクセス制御規則を適用するかどうか決定します。
アクセス拒否時の応答
アクセスが拒否された場合、デフォルトでは Sun ONE Application Server は次のメッセージを返します。
FORBIDDEN. Your client is not allowed access to the restricted object.
別の応答方法を設定したり、アクセス制御オブジェクトごとに異なるメッセージを作成したりすることができます。
特定の ACL で返されるメッセージを変更するには、次の手順を実行します。
- 「ACL」ページで「拒否された時に応答 (Response when denied)」リンクをクリックします。
- 下のフレームで、「次のファイルで応答 (Respond with the following file)」にチェックマークをつけます。
- 絶対 URL または相対 URI を入力し、、「更新 (Update)」をクリックします。
ユーザーは、リダイレクト先の URL または URI にアクセスできる必要があります。
- 「更新 (Update)」をクリックします。
- 上のフレームで「送信 (Submit)」をクリックしてアクセス制御規則を送信します。
- 左ペインで「アプリケーションサーバーインスタンス」を選択して自分のサーバーインスタンスにアクセスし、「変更の適用」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
仮想サーバーのアクセス制御
Sun ONE Application Server のアクセス制御情報である ACL ファイルとドキュメントディレクトリ内の htaccess ファイルは、仮想サーバー別に設定できます。
server.xml ファイルには、1 つまたは複数の acl タグを挿入できます。このタグは、特定の標準 ACL ファイルに関連づけられた ID を定義します。次に例を示します。
<acl id="standard" file="standard.acl">
仮想サーバーがアクセス制御を利用するには、acls 属性に 1 つまたは複数の ACL ファイルの ID の参照を作成する必要があります。たとえば、次のように記述します。
<virtual-server acls="standard">
この設定では、複数の仮想サーバーが同じ ACL ファイルを共有します。仮想サーバーにユーザー - グループ認証を適用するには、定義に 1 つまたは複数の auth-db タグを追加する必要があります。この auth-db タグによって、ACL ファイル内のデータベース名と dbswitch.conf 内の実際のデータベースが接続されます。
次の例は、database 属性を持たない ACL を dbswitch.conf ファイル内の default データベースにマッピングします。
<virtual-server>
<auth-db id="default" database="default"/>
</virtual-server>次のトピックでは、仮想サーバーへのアクセスについて説明します。
仮想サーバーからデータベースへのアクセス
dbswitch.conf ファイルには、ユーザー認証データベースをグローバルに定義できます。このファイルは、サーバーの起動時にだけ読み込まれます。dbswitch.conf ファイル内の LDAP URL に含まれる baseDN は、データベースへのすべてのアクセスのグローバルルートを定義します。これにより、下位互換性が維持されます。新しいインストールでは、ほとんどの場合は baseDN は空です。管理インタフェースを使って仮想サーバーの認証データベースを設定することもできます。
注 管理インタフェースの「アプリケーションサーバーインスタンス」 -> 「セキュリティ」 -> 「ディレクトリサービスの設定」ページでディレクトリを設定すると、dbswitch.conf ファイルが更新されます。
操作方法については、次の各項で説明します。
dbswitch.conf ファイルの使用
dbswitch.conf に含まれる LDAP データベースの dcsuffix 属性は Sun ONE Directory Server スキーマに基づいて DC ツリーのルートを定義します。これは、LDAP URL に含まれる baseDN に基づく相対的な指定です。dcsuffix 属性が指定されている場合、LDAP データベースは Sun ONE Directory Server スキーマに準拠し、一部の動作が変更されます。Sun ONE Directory Server スキーマの詳細と例については、『Sun ONE Application Server Developer's Guide to NSAPI』を参照してください。
すべての仮想サーバーに、単一ディレクトリを示す 1 つまたは複数の auth-db ブロックを定義して、追加情報を定義できます。auth-db ブロック ID は、ACL のデータベースパラメータで参照することができます。仮想サーバーに auth-db ブロックがない場合、ユーザーベースまたはグループベースの ACL は失敗します。
auth-db タグは、ACL のデータベース属性と dbswitch.conf ファイルの間に間接的な制御するための層を定義します。この層を追加すると、仮想サーバーの管理者がアクセスできるデータベースに対して、サーバー管理者は完全にアクセス制御できるようになります。
auth-db の詳細については、『Sun ONE Application Server Developer's Guide to NSAPI』を参照してください。
認証データベースの新規作成
管理インタフェースを使って新しい認証データベースを作成するには、次の手順を実行します。
- 左のペインで「アプリケーションサーバーインスタンス」の「HTTP サーバー」にアクセスします。
- 「仮想サーバー」にアクセスして仮想サーバーを開きます (ノードを展開)。
- 左のペインの仮想サーバーの下に表示される「認証データベース」をクリックします。
「認証データベース」ページに現在のデータベースがリスト表示されます。
- 新しい認証データベースを作成するには、「新規」をクリックします。
「認証データベースの新規」ページが表示されます。
- オンラインヘルプを参照して、必要な情報を入力します。
- 「送信 (Submit)」をクリックします。
- 左のペインで「アプリケーションサーバーインスタンス」を選択してサーバーインスタンスにアクセスし、「変更の適用」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
ユーザーインタフェースによるデータベースの指定
dbswitch.conf ファイルに 1 つまたは複数のユーザー認証データベースを作成すると、仮想サーバーが認証に使用するデータベースを管理インタフェースを使って設定できるようになります。また、管理インタフェースを使って、仮想サーバーが認証に使用する新規に作成するデータベースの定義を dbswitch.conf ファイルから追加することもできます。このためには、新規作成認証データベースと ACL を関連づけ、仮想サーバーが ACL を使用するように設定します。
仮想サーバー用のアクセス制御リストの編集
仮想サーバーの ACL は、仮想サーバーが置かれているサーバーインスタンスの ACL として作成されます。仮想サーバーの ACL のデフォルト設定は、サーバーインスタンスの ACL 設定です。ただし、新しい ACL を定義したり、既存の ACL を編集したりすることができます。
仮想サーバーの既存の ACL を編集するには、次の手順を実行します。
- 左のペインで「アプリケーションサーバーインスタンス」の「HTTP サーバー」にアクセスします。
- 「ACL」を選択し、編集する ACL をクリックします。
- 「ACL ファイルを編集 (Edit ACL File)」をクリックします。
- 「リソースを選択 (Pick a Resource)」の下に表示される「アクセス制御を編集 (Edit Access Control)」をクリックします。
「アクセス制御規則 (Access Control Rules for)」テーブルが表示されます。
- オンラインヘルプを参照して、必要な情報を編集します。
- 「アプリケーションサーバーインスタンス」の「HTTP サーバー」にアクセスします。
- 「仮想サーバー」を選択し、サーバーインスタンスをクリックします。
- 編集ページの ACL リストの下で、仮想サーバーと関連づける ACL を選択します。
- 左ペインで「アプリケーションサーバーインスタンス」を選択して自分のサーバーインスタンスにアクセスし、「変更の適用」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
htaccess ファイルの使用
サーバーのコンテンツ全体を一人で管理することはまれです。エンドユーザーが Sun ONE Application Server にアクセスせずに必要に応じて設定を変更できるように、設定オプションのサブセットへのアクセスを許可することが必要な場合もあります。設定オプションのサブセットは、動的な設定ファイルに保存されます。
Sun ONE Application Server は、動的な設定ファイル htaccess をサポートしています。htaccess ファイルを有効にするには、ユーザーインタフェースを使うか、設定ファイルを編集します。htaccess プラグインは、install_dir/lib ディレクトリに保存されています。
htaccess ファイルとサーバーの標準のアクセス制御を組み合わせて使用できます。標準のアクセス制御は、PathCheck 指令が指定する順序に関係なく、あらゆる htaccess アクセス制御の前に常に適用されます。
注 ユーザー - グループ認証を「基本」に設定している場合、標準と htaccess のいずれのアクセス制御にもユーザー認証を義務づけないでください。標準のサーバーアクセス制御を使用して SSL クライアント認証、および htaccess ファイルを使用して HTTP 基本認証を行うことはできます。
この節には次のトピックがあります。
ユーザーインタフェースによる htaccess の有効化
Sun ONE Application Server が htaccess を使うように設定するときは、次の手順を実行します。
- 「アプリケーションサーバーインスタンス」にアクセスし、「HTTP サーバー」の「仮想サーバー」を選択します。
- 仮想サーバーのインスタンスを選択します。
- 「ドキュメントディレクトリ」タブを選択します。
「追加のドキュメントディレクトリ」ページが表示されます。
仮想サーバーの「ドキュメントディレクトリ」ページ
- 「htaccess 設定」リンクをクリックします。
「htaccess 設定」ページが表示されます。
仮想サーバーの「htaccess 設定」ページ
- 次のいずれかの方法で、編集するサーバーを選択します。
サーバー全体、または特定のサーバーをドロップダウンリストから選択する
「ブラウズ」をクリックして、編集するディレクトリまたはファイルを選択する
「ワイルドカード」をクリックして、編集対象をワイルドカードのパターンで選択する
- 「はい」を選択して htaccess を有効にします。
- htaccess 設定を追加するファイルの名前を入力します。
- 「送信 (Submit)」をクリックします。
- 左ペインで「アプリケーションサーバーインスタンス」を選択して自分のサーバーインスタンスにアクセスし、「変更の適用」をクリックします。
- サーバーを停止し、再起動して変更を適用します。
init.conf による htaccess の有効化
サーバーが htaccess ファイルを使用するように手動で設定するには、サーバーの init.conf ファイルを修正して、プラグインのロード、初期化、有効化を行う必要があります。
- instance_dir/config ディレクトリの init.conf を開きます。
- 一連の初期化指令の最後に次の行を追加します。
UNIX 環境の場合 :
Init fn="load-modules" funcs="htaccess-init,htaccess-find,htaccess-register"
shlib="install_dir/lib/htaccess.so" NativeThread="no"
Init fn="htaccess-init"Windows 環境の場合 :
Init fn="load-modules" funcs="htaccess-init,htaccess-find,htaccess-register"
NativeThread="no"
Init fn="htaccess-init"
- (省略可能) 最後の行を次のように変更します。
Init fn="htaccess-init"[groups-with-users=yes]
- ファイルを保存します。
- obj.conf ファイルを開きます。
- オブジェクトの最後の指令として PathCheck 指令を追加します。
仮想サーバーが管理するすべてのディレクトリで htaccess ファイルの処理を有効にするには、次のように、obj.conf ファイルのデフォルトオブジェクトに PathCheck 指令を追加します。
<Object name="default">
...
PathCheck fn="htaccess-find"
</Object>
htaccess の処理は、オブジェクトの PathCheck 指令の最後に指定する必要があります。
特定のサーバーディレクトリだけで htaccess の処理を有効にするときは、init.conf ファイル内の対応する定義に PathCheck 指令を挿入します。
- htaccess ファイルに htaccess 以外の名前をつけるには、次の形式で PathCheck 指令にファイル名を指定する必要があります。
設定後にサーバーにアクセスすると、指定したディレクトリに htaccess アクセス制御が適用されます。たとえば、htaccess ファイルへの書き込みアクセスを制限するには、ファイルの設定スタイルを作成し、その設定スタイルにアクセス制御を適用します。詳細については、『Applying Configuration Styles』を参照してください。
htaccess-register の使用
htaccess-register を使うことで、独自の認証方法を作成できます。Apache のように、外部認証モジュールやプラグインを作成し、htaccess-register を使って htaccess モジュールに組み込むことができます。
外部モジュールを使って、1 つまたは複数の新しい指令を作成できます。たとえば、認証用のユーザーデータベースを指定できます。指令は、<Limit> タグまたは <LimitExcept> タグの内部に表示されないことがあります。
次に、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 指令
次のトピックでは、Sun ONE Application Server がサポートしている htaccess 指令について説明します。
allow
特定のホストへのアクセスを許可します。通常は、<Limit> タグ内に指定されています。
構文
allow from_host
変数の意味は次のとおりです。
from_host が all の場合、すべてのクライアントホストからのアクセスを許可する
from_host は all または DNS ホスト名の最後の部分
from_host は完全な、または部分的な IP アドレス
<Limit> または <LimitExcept> 内に指定する必要はありませんが、通常はこの中に指定されています。
deny
特定のホストへのアクセスを拒否します。通常は、<Limit> 内に指定されます。
構文
deny from_host
変数の意味は次のとおりです。
from_host が all の場合、すべてのクライアントホストからのアクセスを拒否する
from_host は all または DNS ホスト名の最後の部分
from_host は完全な、または部分的な IP アドレス
<Limit> または <LimitExcept> 内に指定する必要はありませんが、通常はこの中に指定されています。
AuthGroupFile
require group 指令で参照されるグループ定義に使う、名前がつけられたグループファイルを指定します。AuthGroupFile 指令に指定されているファイル名が、AuthUserFile 指令に含まれるファイル名と一致する場合、ファイルには次の形式でユーザーとグループが指定されているものと見なされます。
username:DES-encrypted-password:comma-separated-list-of-groups
構文
AuthGroupFile file_name
変数の意味は次のとおりです。
file_name は次の形式でグループが定義されているファイルの名前
groupname: user user<Limit> または <LimitExcept> 内に指定する必要はありません。
AuthUserFile
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
構文
AuthUserFile filename
変数の意味は次のとおりです。
filename は次の形式でユーザーが定義されているファイルの名前 username:password
変数の意味は次のとおり
username はユーザーのログイン名、パスワードは DES 暗号化パスワード
<Limit> または <LimitExcept> 内に指定する必要はありません。
AuthName
通常はクライアント側のユーザー名とパスワードの入力プロンプトに表示される、認証レルム文字列です。クライアント側でのユーザー名とパスワードのキャッシングに影響します。
構文
AuthName authentication_realm
変数の意味は次のとおりです。
authentication_realm は、ユーザー認証要求と関連づけられた認証レルムを識別する文字列
<Limit> または <LimitExcept> 内に指定する必要はありません。
AuthType
現在サポートされている唯一のユーザー認証方法である HTTP 基本認証を指定します。
構文
AuthType Basic
<Limit> または <LimitExcept> 内に指定する必要はありません。
<Limit>
指定した HTTP メソッドを使った要求だけに対して、このタグで囲まれている指令を適用します。
構文
<Limit method method ...>
allow, deny, order, or require directives
</Limit>
変数の意味は次のとおりです。
method は GET、POST、PUT などの HTTP メソッド。Web サーバーが認識できるメソッドであれば、どれでも使用できる
<LimitExcept>
指定した HTTP 認証方法を使っていない要求だけに対して、このタグで囲まれている指令を適用します。
構文
<LimitExcept method method ...>
allow, deny, order, or require directives
</LimitExcept>
変数の意味は次のとおりです。
method は GET、POST、PUT などの HTTP メソッド。Web サーバーが認識できるメソッドであれば、どれでも使用できる
order
- allow 指令を許可、拒否、評価し、次に deny 指令を許可、拒否、評価する
- deny 指令を拒否、許可、評価し、次に allow 指令を拒否、許可、評価する
- Mutual-failure を指定した場合は、順序に関係なく、allow 指令と deny 指令の両方に指定されているホストへのアクセスは拒否される
構文
order ordering
変数の意味は次のとおりです。
<Limit> または <LimitExcept> 内に指定する必要はありませんが、通常はこの中に指定されています。
require
- requires group を指定した場合は、指定したグループのいずれかに認証するユーザーが含まれている必要がある
- requires user を指定した場合は、指定したユーザーに認証するユーザーが含まれている必要がある
- requires valid user を指定した場合は、ユーザーは認証されている必要がある
構文
requires group groupname groupname
requires user username username
requires valid-user
<Limit> または <LimitExcept> 内に指定する必要はありませんが、通常はこの中に指定されています。