特定のユーザーまたはグループに対して、Web サーバーへのアクセスを制限することができます。ユーザー - グループのアクセス制御を設定した場合、サーバーにアクセスする前に、ユーザーはユーザー名とパスワードの入力を求められます。サーバーは、クライアント証明書内の情報をディレクトリサーバーのエントリと比較します。
管理サーバーでは、基本認証だけを使用します。管理サーバーでクライアント認証を要求する場合、ACL ファイルを手動で編集し、認証方法を SSL に変更する必要があります。
ユーザー - グループ認証は、Web Server がユーザーグループデータベース内のエントリを読み取ることによって実行されます。ディレクトリサービスがアクセス制御の実装に使用する情報は、次のソースのいずれかから入手できます。
内部フラットファイルタイプのデータベース
外部 LDAP データベース
サーバーは、外部 LDAP ベースのディレクトリサービスを使用するとき、サーバーインスタンスに対して次のタイプのユーザーグループ認証方法をサポートします。
デフォルト
基本
SSL
ダイジェスト
その他
サーバーが内部ファイルベースのディレクトリサービスを使用するときに、サーバーインスタンスに対してサポートされるユーザー - グループ認証方法には、次のものがあります。
デフォルト
基本
ダイジェスト
ユーザー - グループ認証では、ユーザーがサーバーにアクセスしたり、Web サイト上のファイルやディレクトリにアクセスしたりするには、まず自身を認証する必要があります。認証を行う場合、ユーザーは、ユーザー名とパスワードを入力したりクライアント証明書を使用したりすることで、自身の身元を確認します。クライアント証明書が必要となるのは、SSL 通信を行う場合だけです。
デフォルト認証は、推奨される方法です。「標準」設定では、server.xml ファイル内のデフォルトの方法が使用されます。ただし、server.xml に設定が含まれていない場合は「基本」が使用されます。「デフォルト」を選択した場合、ACL 規則によって ACL ファイル内のメソッドが指定されることはありません。「標準」を選択すれば、obj.conf ファイル内で 1 行編集することですべての ACL の方法を簡単に変更できます。
基本認証では、ユーザー名とパスワードを入力しないと、Web サーバーまたは Web サイトにアクセスできません。これがデフォルトの設定です。一連のユーザーとグループを作成し、それらを Sun Java System Directory Server などの LDAP データベース内またはファイル内に格納する必要があります。ディレクトリサーバーは、Web サーバーとは異なるサーバールートにインストールされたものか、リモートマシンにインストールされたものを使用する必要があります。
ユーザーが、管理サーバー内や Web サイト上のユーザー - グループ認証が必要なリソースにアクセスしようとすると、ユーザー名とパスワードの入力を求めるダイアログボックスが Web ブラウザによって表示されます。サーバーで暗号化が設定されているかどうかに応じて、サーバーはこの情報を暗号化された状態、または暗号化されていない状態で受信します。
SSL 暗号化なしで基本認証を使用する場合、暗号化されていないユーザー名とパスワードがネットワークを経由して送信されます。ネットワークパケットは傍受される可能性があり、ユーザー名とパスワードが不正に知られてしまう可能性があります。基本認証は、SSL 暗号化またはホスト - IP 認証、あるいはその両方と組み合わせるのがもっとも効果的です。ダイジェスト認証を使えばこの問題を回避できます。
サーバーは、次の 2 つの方法で、セキュリティー証明書付きのユーザーの識別情報を確認できます。
クライアント証明書の情報を識別情報の証明として使用する
LDAP ディレクトリで発行されたクライアント証明書を確認する (追加)
クライアントの認証で証明書の情報を使用するようにサーバーを設定した場合、サーバーは次の処理を実行します。
まず、証明書が信頼できる CA からのものであるか確認します。そうでない場合、認証は失敗し、トランザクションが終了します。
証明書が信頼できる認証局 (CA) からのものである場合、certmap.conf ファイルを使ってその証明書をユーザーのエントリにマップします。
証明書が正しくマップされている場合は、そのユーザーに対して指定されている ACL 規則を確認します。証明書が正しくマップされている場合でも、ACL 規則によってユーザーのアクセスが拒否される可能性もあります。
特定のリソースへのアクセスを制御するためにクライアント認証を要求することは、サーバーへの接続のすべてに対してクライアント認証を要求することとは異なります。すべての接続に対してクライアント認証を要求するようにサーバーを設定した場合、クライアントは信頼できる CA によって発行された有効な証明書のみを提示する必要があります。SSL の方法を使ってユーザーとグループを認証するようにサーバーのアクセス制御を設定した場合、クライアントで次のことが必要になります。
信頼できる CA から発行された有効な証明書を提供する
証明書は LDAP 内の有効なユーザーにマッピングされている
アクセス制御リストで、適切に評価される
アクセス制御でクライアント認証を要求する場合、Web サーバーの SSL 暗号化方式を有効にする必要があります。
SSL で認証されるリソースにアクセスするには、Web サーバーが信頼している CA から、クライアント証明書が発行されている必要があります。ブラウザのクライアント証明書とディレクトリサーバーのクライアント証明書を比較するように Web サーバーの certmap.conf ファイルが設定されている場合、クライアント証明書はディレクトリサーバーで発行されている必要があります。ただし、証明書から選択した情報とディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することもできます。たとえば、ブラウザ証明書のユーザー ID および電子メールアドレスとディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することができます。
SSL 認証方法の場合にのみ、certmap.conf ファイルを変更する必要があります。なぜなら、この方法では、LDAP ディレクトリに基づいて証明書がチェックされるからです。サーバーへのすべての接続に対してクライアント認証を要求する場合は、その必要はありません。クライアント証明書を使用することを選択する場合、magnus.conf の AcceptTimeout 指令の値を増やすべきです。
サーバーは、LDAP ベースまたはファイルベースのいずれかのディレクトリサービスを使用して、ダイジェスト認証を行うように設定できます。
ダイジェスト認証を使えば、ユーザー名とパスワードを平文として送信することなしに、ユーザー名とパスワードに基づく認証を行えます。ブラウザは MD5 アルゴリズムを使用して、ユーザーのパスワードと Web Server によって提供される情報の一部を使用するダイジェスト値を作成します。
サーバーが LDAP ベースのディレクトリサービスを使用してダイジェスト認証を行うとき、このダイジェスト値は、ダイジェスト認証プラグインを使用してサーバー側で計算され、クライアントによって提示されたダイジェスト値と比較されます。ダイジェスト値が一致した場合、ユーザーは認証されます。これが機能するには、ディレクトリサーバーが平文形式のユーザーのパスワードにアクセスできる必要があります。Sun Java System Directory Server にはリバーシブルパスワードプラグインが組み込まれています。このプラグインは、対称暗号化アルゴリズムを使用し、暗号化された形式にしてデータを格納し、あとで元の形式に復号化することができます。データへの鍵を持っているのは Directory Server だけです。
LDAP ベースのダイジェスト認証の場合、リバーシブルパスワードプラグインと、サーバーに組み込まれているダイジェスト認証専用のプラグインを有効にする必要があります。ダイジェスト認証を処理するように Web サーバーを構成するには、dbswitch.conf 内のデータベース定義の digestauth プロパティーを設定します。
ACL 方式を指定しない場合、認証が必要であればダイジェスト認証または基本認証のいずれかが使用され、認証が必要ない場合は基本認証が使用されます。これが推奨される方法です。
表 7–1 ダイジェスト認証要求の生成
ACL 方式 |
認証データベースでダイジェスト認証がサポートされている |
認証データベースでダイジェスト認証がサポートされていない |
---|---|---|
「標準」 指定されていない |
ダイジェストと基本 |
基本 |
「基本」 |
基本 |
基本 |
「ダイジェスト」 |
ダイジェスト |
エラー |
method = digest を含む ACL を処理する場合、サーバーは次のようにして認証を試みます。
Authorization 要求ヘッダーをチェックします。見つからない場合は、ダイジェスト要求に対して 401 の応答が生成され、プロセスが停止します。
認証のタイプを確認します。認証のタイプがダイジェストの場合、サーバーは次のことを実行します。
ノンスをチェックします。このサーバーによって生成された、有効で新しい nonce がない場合は、401 の応答が生成されてプロセスが停止します。期限切れの場合は、stale=true で 401 応答が生成され、処理が停止します。
ノンスの有効期間を構成するには、magnus.conf ファイル内のパラメータ DigestStaleTimeout の値を変更します。このファイルは server_root/https-server_name/config/ にあります。この値を設定するには、次の行を magnus.conf に追加します。
ここで seconds は、nonce の有効期限 (秒) です。指定されている秒数が経過すると、nonce の有効期限は切れ、ユーザーからの新しい認証が必要になります。
レルムをチェックします。これが一致しない場合は、401 応答が生成され、処理が停止します。
認証ディレクトリが LDAP ベースの場合は LDAP ディレクトリにユーザーが存在するかどうかを確認します。認証ディレクトリがファイルベースの場合はファイルデータベースにユーザーが存在するかどうかを確認します。見つからない場合は、401 応答が生成され、処理が停止します。
ディレクトリサーバーまたはファイルデータベースから要求ダイジェスト値を取得し、クライアントの要求ダイジェストと一致するかどうかをチェックします。一致しない場合は、401 応答が生成され、処理が停止します。
Authorization-Info ヘッダーを構築し、サーバーヘッダーに挿入します。