アクセス制御により、Proxy Server にアクセスできるユーザー、およびアクセス可能なサーバーの部分を指定することができます。サーバーへのアクセスの制御は、サーバー全体に対して、またはディレクトリ、ファイル、ファイルタイプなどのサーバーの一部に対して行うことができます。受信した要求が評価される場合、アクセス制御エントリ (Access Control Entry、ACE) と呼ばれる規則の階層に基づいてアクセスが決定されます。Proxy Server は一致するエントリを検索して、アクセスを許可するか、拒否するかを決定します。各 ACE は、サーバーが階層内の次のエントリに進むべきかどうかを指定します。ACE の集合は、アクセス制御リスト (ACL) と呼ばれます。要求を受信すると、obj.conf ファイルでアクセスの決定に使用される ACL の参照がチェックされます。デフォルトでは、サーバーには複数の ACL が含まれる 1 つの ACL ファイルがあります。
アクセスは次の内容に基づいて許可または拒否されます。
要求を送信したユーザー (ユーザー - グループ)
要求の送信元 (ホスト - IP)
要求が発生した日時 (時刻など)
使用されている接続のタイプ (SSL)
ここでは、次の内容について説明します。
特定のユーザーまたはグループに対して、サーバーへのアクセスを制限することができます。ユーザー - グループのアクセス制御を設定した場合、サーバーにアクセスする前に、ユーザーはユーザー名とパスワードの入力を求められます。サーバーは、クライアント証明書の情報、またはクライアント証明書自体を、ディレクトリサーバーのエントリと比較します。
管理サーバーでは、基本認証だけを使用します。管理サーバーでクライアント認証を要求する場合、obj.conf の ACL ファイルを手動で編集し、認証方法を SSL に変更する必要があります。
ユーザー - グループ認証は、サーバーに設定されているディレクトリサービスによって実行されます。詳細は、「ディレクトリサービスの設定」を参照してください。
ディレクトリサービスがアクセス制御の実装に使用する情報は、次のソースのいずれかから入手できます。
内部フラットファイルタイプのデータベース
外部 LDAP データベース
サーバーは、外部 LDAP ベースのディレクトリサービスを使用するとき、サーバーインスタンスに対して次のタイプのユーザーグループ認証方法をサポートします。
デフォルト
基本
SSL
ダイジェスト
その他
サーバーが内部ファイルベースのディレクトリサービスを使用するときに、サーバーインスタンスに対してサポートされるユーザー - グループ認証方法には、次のものがあります。
デフォルト
基本
ダイジェスト
ユーザー - グループ認証を設定した場合、ユーザーはアクセスする前に、ユーザー自身の認証を求められます。認証の際、ユーザーはユーザー名とパスワードの入力、クライアント証明書の使用、またはダイジェスト認証プラグインを使用することによってユーザー自身の識別情報を証明します。クライアント証明書を使用する場合、暗号化が必要になります。
デフォルト認証は、推奨される方法です。デフォルト設定では、obj.conf ファイルで指定したデフォルトの方法を使用します。obj.conf で方法が設定されていない場合は、「Basic」を使用します。「Default」を選択した場合、ACL 規則によって ACL ファイル内の方法が指定されることはありません。「Default」を選択すると、obj.conf ファイル内の 1 行を編集することによって、すべての ACL の方法を簡単に変更できます。
基本認証を選択した場合、サーバーにアクセスするためにユーザーはユーザー名とパスワードの入力を求められます。基本認証がデフォルトの設定です。Sun Java System Directory Server などの LDAP データベース、またはファイルにユーザーとグループのリストを作成して格納する必要があります。Proxy Server とは別のサーバールートにインストールされたディレクトリサーバー、またはリモートコンピュータにインストールされたディレクトリサーバーを使用する必要があります。
ユーザーがユーザー - グループ認証を行うリソースへアクセスしようとすると、ユーザー名とパスワードの入力を求められます。サーバーで暗号化が設定されている (SSL が有効) かどうかに応じて、サーバーはこの情報を暗号化された状態、または暗号化されていない状態で受信します。
SSL 暗号化なしで基本認証を使用する場合、暗号化されていないユーザー名とパスワードがネットワークを経由して送信されます。ネットワークパケットは傍受される可能性があり、ユーザー名とパスワードが不正に知られてしまう可能性があります。基本認証は、SSL 暗号化とホスト - IP 認証のどちらか、またはその両方と組み合わせた場合にもっとも効果的です。ダイジェスト認証を使用しても、この問題を回避できます。
認証に成功した場合、ユーザーには要求されたリソースが表示されます。ユーザー名またはパスワードが無効な場合は、アクセスが拒否されたことを示すメッセージが発行されます。
承認されていないユーザーから受信するメッセージはカスタマイズできます。詳細は、「アクセスが拒否された場合の応答」を参照してください。
サーバーは、次の 2 つの方法で、セキュリティー証明書付きのユーザーの識別情報を確認できます。
クライアント証明書の情報を識別情報の証明として使用する
LDAP ディレクトリで発行されたクライアント証明書を確認する (追加)
クライアントの認証で証明書の情報を使用するようにサーバーを設定した場合、サーバーは次の処理を実行します。
信頼できる CA (認証局) から発行された証明書かどうかを確認します。そうでない場合、認証は失敗し、トランザクションが終了します。クライアント認証を有効にする方法については、「セキュリティーに関する詳細設定」を参照してください。
証明書が信頼できる CA から発行されたものである場合は、certmap.conf ファイルを使用して、証明書をユーザーのエントリにマップします。証明書マッピングファイルの設定方法については、「certmap.conf ファイルの使用」を参照してください。
証明書が正しくマップされている場合は、そのユーザーに対して指定されている ACL 規則を確認します。証明書が正しくマップされている場合でも、ACL 規則によってユーザーのアクセスが拒否される可能性もあります。
特定のリソースへのアクセスを制御するためにクライアント認証を要求することは、サーバーへの接続のすべてに対してクライアント認証を要求することとは異なります。すべての接続に対してクライアント認証を要求するようにサーバーを設定した場合、クライアントは信頼できる CA によって発行された有効な証明書のみを提示する必要があります。ユーザーとグループの認証に SSL メソッドを使用するようにサーバーを設定した場合、次のことが行われます。
クライアントは信頼できる CA によって発行された有効な証明書を提示する
証明書は LDAP 内の有効なユーザーにマッピングされている
アクセス制御リストで、適切に評価される
アクセス制御を使用してクライアント認証を要求する場合、Proxy Server で SSL 暗号化方式を有効にする必要があります。SSL の有効化については、第 5 章証明書と鍵の使用を参照してください。
SSL で認証されるリソースにアクセスするには、Proxy Server により信頼できる CA から、クライアント証明書が発行されている必要があります。ブラウザのクライアント証明書とディレクトリサーバーのクライアント証明書を比較するように Proxy Server の certmap.conf ファイルが設定されている場合、クライアント証明書はディレクトリサーバーで発行されている必要があります。ただし、証明書から選択した情報とディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することもできます。たとえば、ブラウザ証明書のユーザー ID および電子メールアドレスとディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することができます。certmap.conf と証明書マッピングについては、第 5 章証明書と鍵の使用を参照してください。『Sun Java System Web Proxy Server 4.0.8 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 プロパティーを設定します。
dbswitch.conf ファイルの例を次に示します。
directory default ldap://<host_name>:<port> default:binddn cn=Directory Manager default:encoded bindpw *********** default:digestauth on |
または、
directory default ldap://<host_name>:<port>/ default:binddn cn=Directory Manager default:encoded bindpw *********** default:digestauthstate on |
サーバーは、指定されている ACL 方式に基づいて、LDAP データベースに対して認証を試みます。「ダイジェスト認証」を参照してください。ACL 方式を指定しない場合、認証が必要であればダイジェスト認証または基本認証のいずれかが使用され、認証が必要ない場合は基本認証が使用されます。
次の表は、認証データベースでサポートされる、あるいはサポートされないダイジェスト認証を示しています。
表 8–1 ダイジェスト認証チャレンジの生成
ACL 方式 |
認証データベースでサポートされる方式 |
認証データベースでサポートされない方式 |
---|---|---|
デフォルト 指定されていない |
ダイジェストと基本 |
基本 |
基本 |
基本 |
基本 |
ダイジェスト |
ダイジェスト |
エラー |
method=digest を指定して ACL を処理する場合、サーバーは次のことを実行して認証を試みます。
認証要求のヘッダーを確認します。ヘッダーが見つからない場合は、ダイジェストチャレンジに対して 401 の応答が生成され、プロセスが停止します。
認証のタイプを確認します。認証のタイプがダイジェストの場合、サーバーは次のことを実行します。
nonce を確認します。このサーバーによって生成された、有効で新しい nonce がない場合は、401 の応答が生成されてプロセスが停止します。nonce が無効な場合は、stale=true として 401 の応答が生成され、プロセスが停止します。
server-root /proxy-server_name/config/ にある magnus.conf ファイルの DigestStaleTimeout パラメータ値を変更することで、nonce の有効期限を設定できます。この値を設定するには、次の行を magnus.conf に追加します。
DigestStaleTimeout seconds
ここで seconds は、nonce の有効期限 (秒) です。指定されている秒数が経過すると、nonce の有効期限は切れ、ユーザーからの新しい認証が必要になります。
レルムを確認します。一致するものが見つからない場合は、401 の応答が生成されてプロセスが停止します。
認証ディレクトリが LDAP ベースの場合は LDAP ディレクトリにユーザーが存在するかどうかを確認します。認証ディレクトリがファイルベースの場合はファイルデータベースにユーザーが存在するかどうかを確認します。ユーザーが見つからない場合は、401 の応答が生成されてプロセスが停止します。
ディレクトリサーバーまたはファイルデータベースから request-digest 値を取得し、クライアントの request-digest 値と一致する値があるかを調べます。一致するものが見つからない場合は、401 の応答が生成されてプロセスが停止します。
Authorization-Info ヘッダーを構築し、サーバーヘッダーに挿入します。
LDAP ベースのディレクトリサービスを使用するダイジェスト認証の場合、ダイジェスト認証プラグインをインストールする必要があります。このプラグインは、サーバー側でダイジェスト値を計算し、この値をクライアントによって提供されるダイジェスト値と比較します。ダイジェスト値が一致した場合、ユーザーは認証されます。
ファイルベースの認証データベースを使用する場合、ダイジェスト認証プラグインをインストールする必要はありません。
ダイジェスト認証プラグインは、共用ライブラリと ldif ファイルで構成されています。
この共用ライブラリが、Sun Java System Directory Server がインストールされているのと同じサーバーコンピュータにあることを確認します。
ディレクトリマネージャーのパスワードを確認します。
/path/to へのすべての参照が、ダイジェストプラグインの共用ライブラリのインストール先に変更されるように、libdigest-plugin.ldif ファイルを修正します。
プラグインをインストールするには、次のコマンドを入力します。
% ldapmodify -D "cn=Directory Manager" -w password -a < libdigest-plugin.ldif
ダイジェストプラグインとともに Sun Java System Directory Server コンピュータが正しく起動できるようにするには、Proxy Server のいくつかの .dll ファイルを Directory Server コンピュータにコピーする必要があります。
server-root \bin\proxy\bin にある Proxy Server の共用ライブラリにアクセスします。
ファイル nsldap32v50.dll、libspnr4.dll、および libplds4.dll を適切なディレクトリにコピーします。
これらのファイルを次の両方の場所にペーストします。
DES アルゴリズムは、ダイジェストパスワードが格納されている属性を暗号化するために必要です。
Sun Java System Directory Server コンソールを起動します。
Sun ONE Directory Server 5.1 SP1 (またはそれ以降のバージョン) のインスタンスを開きます。
Configuration タブを選択します。
プラグインの横の + 記号をクリックします。
DES プラグインを選択します。
「Add」を選択して新しい属性を追加します。
iplanetReversiblePassword と入力します。
「保存 (Save)」をクリックします。
ダイジェスト認証のパスワードを設定します。
サーバーは、オブジェクトクラス iplanetReversiblePassword 内にある iplanetReversiblePassword 属性を使用します。iplanetReversiblePassword 属性でユーザーのダイジェスト認証のパスワードを使用するには、エントリに iplanetReversiblePasswordobject オブジェクトを含める必要があります。
これを行なうには、ldapmodify を使用するか、Directory Server 管理インタフェースを使用します。
ldapmodify を使用する場合—
digest.ldif ファイルを作成して、LDAP のコマンドを格納します。パスワードを追加するには、手順が 2 つあります。
オブジェクトクラスを digest.ldif に追加します。
このファイルは、次のようになっています (Directory Server ユーザーと ACL に応じて、複数の ldif ファイルがあることがあります)。
dn:uid=user1,dc=india,dc=sun,dc=com changetype:modify add:objectclass objectclass:iplanetReversiblePasswordobject dn:uid=user1,dc=india,dc=india,dc=sun,dc=com changetype:modify add:iplanetReversiblePassword iplanetReversiblePassword:user1 |
# ldapmodify -D “cn={CN_Value}” -w <password> -a <ldif_file_name>
Sun Java System Directory Server インスタンスを再起動し、ユーザーの属性が Directory Server データベースに追加されたことを確認します。
アクセス制御 API を使用すると、カスタムの認証方法を作成できます。
管理サーバーおよびそのファイルとディレクトリに対して、特定のコンピュータを使用しているクライアントだけが利用できるように、アクセスを制限できます。そのためには、アクセスの許可または拒否を行うコンピュータのホスト名または 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 ファイルから参照することができます。また、時刻や曜日を基準にしたサーバーへのアクセス制限など、ファイルを編集するだけで利用できる機能もいくつかあります。
アクセス制御ファイルとその構文については、第 18 章ACL ファイルの構文を参照してください。server.xml については、『Sun Java System Web Proxy Server 4.0.8 Configuration File Reference』を参照してください。
デフォルトでは、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 が有効になっている場合、アクセス制御とともにクライアント証明書を使用できます。特定のリソースへのアクセスにクライアント証明書が必要であることを指定する必要があります。サーバーでこの機能を有効にした場合、証明書を持つユーザーは、制限されたリソースに初めてアクセスを試みる場合にのみ、名前とパスワードを入力します。ユーザーの識別情報がいったん確立されると、サーバーはログイン名とパスワードを個々の証明書にマップします。その後、ユーザーはクライアント認証の必要なリソースにアクセスする場合、ログイン名とパスワードを入力する必要がなくなります。
ユーザーが制限されたリソースへのアクセスを試みた場合、ユーザーのクライアントはクライアント証明書をサーバーに送信し、サーバーはこれをマッピングリストと照合します。証明書がアクセス権を付与したユーザーのものである場合、リソースが提供されます。
特定のリソースへのアクセスを制御するためにクライアント認証を要求することは、サーバーへの接続のすべてに対してクライアント認証を要求することとは異なります。また、すべての SSL 接続にクライアント証明書を要求しても、証明書が自動的にデータベース内のユーザーにマップされないことに注意してください。このマッピングを設定するには、特定のリソースへのアクセスにクライアント証明書が必要であることを指定する必要があります。