この章では、Sun Java System Web Server にアクセス可能なユーザーとグループを追加、削除、および編集する方法について説明します。
管理サーバーを使用して、ユーザーアカウント、グループリスト、アクセス特権 (ACL)、組織単位、およびその他のユーザーやグループに固有の情報に関するアプリケーションデータにアクセスできます。
ユーザーとグループの情報は、テキスト形式のフラットファイルに格納されるか、あるいは Sun Java System Directory Server など、LDAP (Lightweight Directory Access Protocol) をサポートするディレクトリサーバー内に格納されます。LDAP は TCP/IP 上で実行されるオープンなディレクトリアクセスプロトコルであり、グローバルなサイズと数百万件のエントリにも対応可能なスケーラビリティーを備えています。
Sun Java System Directory Server などのディレクトリサーバーを使えば、単一のアプリケーションからすべてのユーザー情報を管理できます。また、サーバーを設定して、簡単にアクセスできる複数のネットワークロケーションからユーザーがディレクトリ情報を引き出せるようにすることもできます。
Web Server 7.0 では、ユーザーやグループを認証および承認するために、異なる 3 つのタイプのディレクトリサービスを構成できるようになっています。ディレクトリサービスが設定されていない場合、作成される新しいディレクトリサービスには、種類に関係なく default という値が設定されます。
ディレクトリサービスを作成すると、そのディレクトリサービスの詳細情報に基づいて server.xml ファイルが更新されます。
Web Server 7.0 でサポートされているディレクトリサービスのタイプは、次のとおりです。
LDAP — ユーザーとグループの情報を、LDAP ベースのディレクトリサーバー内に格納します。
鍵ファイル — 鍵ファイルとは、ハッシュ形式のユーザーパスワード、およびそのユーザーが所属するグループのリストが含まれているテキストファイルです。鍵ファイル内に格納されたユーザーやグループは、file レルムによってのみ、認証や承認用として使用されます。これらは、システムのユーザーやグループとは何の関係もありません。
鍵ファイル形式は、HTTP 基本認証の使用を目的としている場合にだけ使用できます。
ダイジェストファイル — ユーザーとグループの情報を、暗号化されたユーザー名とパスワードに基づいて格納します。
ダイジェストファイル形式の目的は、HTTP ダイジェスト認証の使用をサポートすることです。ただし、これは基本認証もサポートしており、どちらの認証方法にも使用できるようになっています。
分散管理を設定する場合、デフォルトのディレクトリサービスは LDAP ベースのディレクトリサービスでなければいけません。
ユーザーとは、企業の社員などのような、LDAP データベース内の個人を意味します。グループとは、同じ属性を共有する複数のユーザーを意味します。組織単位とは企業内の 1 部門のことです。
企業内のユーザーやグループはそれぞれ、識別名 (DN) 属性によって表現されます。DN 属性は、関連するユーザー、グループ、またはオブジェクトを識別する情報が含まれているテキスト文字列です。ユーザーまたはグループのディレクトリエントリを変更する場合は常に、DN を使用します。たとえば、ディレクトリエントリを作成または変更したり、アクセス制御を設定したり、メールやバブリッシングといったアプリケーションのユーザーアカウントを設定したりするたびに、DN 情報を指定する必要があります。
上図にサンプルの DN 表現を示します。次の例は、Sun Microsystems の従業員の典型的な DN を表したものです。
uid=doe,e=doe@sun.com,cn=John Doe,o=Sun Microsystems Inc.,c=US
この例で、各等号の前にある略語の意味は次のとおりです。
uid: ユーザー ID
e: 電子メールアドレス
cn: ユーザーの共通名
o: 組織
c: 国
DN には、さまざまな名前と値のペアを含めることができます。これらは、LDAP をサポートするディレクトリ内における、証明書のサブジェクトとエントリの両方を識別するために使用されます。
現在、ディレクトリが存在しない、または既存のディレクトリに新規のサブツリーを追加したい場合、Directory Server の管理サーバー LDIF インポート機能を使用できます。この機能を使用すれば、LDIF を含むファイルを取り扱うことができ、ディレクトリを構築したり、LDIF エントリから新規のサブツリーを構築したりすることが可能です。また、Directory Server の LDIF エクスポート機能を使用して、現在のディレクトリを LDIF へエクスポートすることもできます。この機能は、該当するディレクトリを表す LDIF 形式のファイルを作成します。ldapmodify コマンドと適切な LDIF 更新文を組み合わせることで、エントリを追加または編集します。
LDIF を使ってデータベースにエントリを追加するには、まず LDIF ファイル内でエントリを定義し、次にその LDIF ファイルを Directory Server でインポートします。
「認証データベース」(auth-db とも呼ばれる) は、既知のユーザーのデータベースを表すとともに、そのデータベースに基づいてクライアント要求を認証するための機構を表します。サーバーでは複数の auth-db エントリを同時に構成することができます。これらは同じタイプであってもかまいません。auth-db ユーザーデータベースは ACL 処理モジュールによって使用されます。
サーバーでサポートされる認証データベースは、次のとおりです。
LDAP — Sun Java System Directory Server などの LDAP ディレクトリサーバー内にユーザーデータが格納されます。
ファイル— ディスクファイル内にユーザーデータが格納されます。この auth-db は、ユーザーの集中管理が利用可能でない (あるいは望ましくない) ような開発用途や小規模配備用途に特に便利です。ファイル auth-db は、いくつかの異なるファイル形式をサポートしています。
keyfile — keyfile 形式では、ユーザーのリスト (およびオプションで各ユーザーのグループメンバーシップ) が格納されます。パスワードは単方向の (復元不可能な) ハッシュとして格納されます。これがデフォルトの形式です。
digestfile — digestfile は、keyfile によく似ていますが、さらに HTTP ダイジェスト認証方法もサポートします。
htaccess — これは旧バージョンの形式であり、決して新規インストール時や新しいユーザーを追加する場合に使用すべきではありません。
PAM — PAM は、Sun Java System Web Server 7.0 でサポートされる新しい auth-db です。PAM auth-db は、Solaris PAM スタックに認証を委任します。これにより、Web Server システム上の既存の Solaris ユーザーを Web Server に対しても認証することが可能となります。
PAM auth-db は Solaris 9 および 10 (またはそれ以上) でしかサポートされておらず、さらに Web Server インスタンスを root として実行する必要があります。
管理コンソール経由で認証データベースを作成するには、「構成」>「構成名」>「アクセス制御」>「認証データベース」>「新規」ボタンをクリックします。フィールドの説明については、管理コンソールのインラインヘルプを確認してください。選択された認証データベースに応じてフィールドが変わります。たとえば、PAM ベースの認証データベースの場合、認証データベース名だけが必須です。
認証データベース作成時の必須オプションを、次に列挙します。
LDAP |
|
鍵ファイル |
|
ダイジェストファイル |
|
PAM |
|
CLI 経由で認証データベースを作成するには、次のコマンドを実行します。
wadm> create-authdb --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config=config1 --url=ldap://ldapserver.com:20002/dc=xxx,dc=sun,dc=com LDAP1 |
CLI リファレンスの create-authdb(1) を参照してください。
上の例では、認証データベースの URL が指定されています。認証データベースのタイプは、この URL のスキーマで指定します。たとえば、ldap://ds.example.com/dc=example,dc=com の場合、LDAP ディレクトリサーバーが認証データベースとして構成されます。
管理サーバーでは、LDAP、ファイルのどちらの auth-db タイプの場合でも、ユーザーアカウント、グループリスト、アクセス特権、組織単位など、ユーザー固有、グループ固有の情報を編集できます。
構成を選択します。
構成のリストから構成を選択します。リストを取得するには「構成」タブをクリックします。
「アクセス制御」>「ユーザー」タブをクリックします。
「新規」ボタンをクリックします。
ユーザー情報を追加します。
ユーザー ID とパスワードを入力します。任意で、ユーザーが属するグループを入力します。ユーザー ID は一意である必要があります。LDAP ベースの認証データベースの場合、管理サーバーは、ユーザー ID が一意であることを確認するために、検索ベース (ベース DN) から下方にディレクトリ全体を検索し、そのユーザー ID が使用されているか確認します。ただし、Directory Server の ldapmodify コマンド行ユーティリティー (使用可能な場合) を使ってユーザーを作成する場合、ユーザー ID の一意性の確認は行われないことに注意してください。
CLI の使用
CLI 経由でユーザーを作成するには、次のコマンドを実行します。
wadm> create-user --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config=config1 --authdb=KEYFILE1 --full-name=keyfile-config1-u1 keyfile-config1-u1 |
CLI リファレンスの create-user(1) を参照してください。
構成を選択します。
構成のリストから構成を選択します。リストを取得するには「構成」タブをクリックします。
「アクセス制御」>「グループ」タブをクリックします。
「新規」ボタンをクリックします。
グループ名を入力します。
「グループへのユーザーの追加」セクションで、既存のユーザーを検索してグループに追加します。
keyfile や digestfile などの認証データベースでグループを作成するには、少なくとも 1 つのユーザーを指定する必要があります。
CLI の使用
CLI 経由でグループを作成するには、次のコマンドを実行します。
wadm> create-group --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config=config1 --authdb=LDAP1 group1 |
CLI リファレンスの create-group(1) を参照してください。
構成を選択します。
構成のリストから構成を選択します。リストを取得するには「構成」タブをクリックします。
「アクセス制御」>「ユーザー」タブをクリックします。
ユーザーを削除する必要のある認証データベースを選択します。
「グループの検索」テキストフィールドにグループ名を入力し、「検索」ボタンをクリックします。
「グループ名」列からグループを選択し、「削除」ボタンをクリックします。
keyfile/digestfile 認証データベースから 1 人以上のユーザーを削除すると、それらのユーザーの削除後に関連する 1 つ以上のグループのメンバーが 1 人もいなくなる場合には、それらのグループも削除されます。これは、メンバーを持たないグループは、keyfile/digestfile 認証データベースでは許可されないからです。
CLI の使用
CLI 経由でユーザーを削除するには、次のコマンドを実行します。
wadm> delete-user --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config config1 --authdb KEYFILE1 user1 |
CLI リファレンスの delete-user(1) を参照してください。
構成を選択します。
構成のリストから構成を選択します。リストを取得するには「構成」タブをクリックします。
「アクセス制御」>「グループ」タブをクリックします。
グループを削除する必要のある認証データベースを選択します。
「ユーザーの検索」テキストボックスにユーザー ID を入力し、「検索」ボタンをクリックします。
「ユーザー ID」列からユーザーを選択し、「削除」ボタンをクリックします。
グループを削除しても、そのグループに属するユーザーは削除されません。ユーザーを手動で削除するか、グループを割り当て直す必要があります。
CLI の使用
CLI 経由でグループを削除するには、次のコマンドを実行します。
wadm> delete-group --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config config1 --authdb LDAP1 group1 |
CLI リファレンスの delete-group(1) を参照してください。
グループとは、LDAP データベース内の一連のオブジェクトを記述するオブジェクトのことです。Web Server 7.0 のグループは、共通の属性を共有するユーザーから構成されます。たとえば、会社のマーケティング部門で働く多数の従業員がオブジェクトのセットになります。これらの従業員は、Marketing という名前のグループに所属させることができます。
LDAP サービスに対しては、グループのメンバーシップを定義する方法が 2 つあります。スタティックとダイナミックです。スタティックグループは、自身のメンバーオブジェクトを明示的に列挙します。スタティックグループは CN であり、uniqueMember、memberURL、memberCertDescription のいずれかまたはその任意の組み合わせを含みます。スタティックグループでは、メンバーは CN=<Groupname> 属性以外の共通属性を共有しません。
ダイナミックグループでは、LDAP URL を使用してグループメンバーにだけ一致する規則セットを定義できます。ダイナミックグループでは、メンバーは memberURL フィルタに定義される 1 つの属性または一連の属性を共有します。たとえば、営業部門のすべての従業員を含むグループが必要で、それらの従業員がすでに LDAP データベース内の
「ou=Sales,o=sun」の下に存在している場合、次の memberurl を含むダイナミックグループを定義します。
ldap:///ou=Sales,o=sun??sub?(uid=*)
結果として、このグループには、「ou=Sales,o=sun」ポイントの下のツリーに uid 属性を持つすべてのオブジェクト、つまりすべての Sales メンバーが含まれます。
スタティックおよびダイナミックグループで、memberCertDescription を使用している場合は、メンバーは証明書から共通属性を共有できます。ただし、これらは、ACL が SSL メソッドを使用している場合にだけ機能します。
新しいグループの作成が完了すると、そのグループにユーザーつまりメンバーを追加できます。
LDAP サービスでは、管理サーバーを使用し、任意のユーザー数の DN に同じグループ属性を指定して、スタティックグループを作成できます。ユーザーが追加または削除されないかぎり、スタティックグループが変わることはありません。
管理サーバーのフォームを使って新しいスタティックグループを作成する場合には、次の指針を参考にしてください。
スタティックグループには、その他のスタティックグループまたはダイナミックグループを含めることができます。
オプションで、新しいグループの説明を追加することもできます。
定義済みの組織単位がディレクトリに存在している場合、「新規グループの追加先」リストを使って新しいグループの配置場所を指定できます。デフォルトの場所は、ディレクトリのルートポイント、つまり最上位のエントリです。
ダイナミックグループは groupOfURLs オブジェクトクラスと 0 個以上の memberURL 属性を持ちます。各 memberURL 属性は、一連のオブジェクトを記述する LDAP URL です。
LDAP サービスに対しては、任意の属性に基づいてユーザーを自動的にグループ化する場合、または一致する DN を含む特定のグループに ACL を適用する場合に、Web Server でダイナミックグループを作成できます。たとえば、属性 department=marketing 持つすべての DN を自動的に含めるグループを作成できます。department=marketing を目的とする検索フィルタを適用すると、この検索によって、属性 department=marketing を持つすべての DN を含むグループが返されます。次に、このフィルタに基づいて検索結果からダイナミックグループを定義できます。さらに、結果として生成されるダイナミックグループの ACL を定義できます。
Web Server は、LDAP サーバースキーマ内でダイナミックグループを objectclass = groupOfURLs として実装しています。groupOfURLS クラスは memberURL 属性を複数持つことができます。各 memberURL 属性は、ディレクトリ内の一連のオブジェクトを列挙する単一の LDAP URL で構成されます。グループのメンバーは、これらのセットの和集合です。たとえば、次のグループにはメンバー URL が 1 つだけ含まれています。
ldap:///o=mcom.com??sub?(department=marketing)
この例は、「o=mcom.com」の下にある、department が「marketing」になっているすべてのオブジェクトから成るセットを示したものです。LDAP URL には、検索ベース DN、スコープ、フィルタは含められますが、ホスト名やポートは含められません。つまり、同じ LDAP サーバー上のオブジェクトだけを参照できます。すべてのスコープがサポートされます。
グループに DN を個別に追加しなくても、すべての DN が自動的に組み込まれます。Sun Java System Web Server は ACL 検証でグループ検索が必要になるたびに LDAP サーバー検索を行うため、グループは動的に変化します。ACL ファイルで使用されるユーザー名とグループ名は、LDAP データベース内のオブジェクトの cn 属性に対応します。
Web Server は、cn (commonName) 属性を ACL のグループ名として使用します。
ACL から LDAP データベースへのマッピングは、dbswitch.conf 構成ファイル (ACL データベース名と実際の LDAP データベース URL を関連付ける) と ACL ファイル (どの ACL でどのデータベースが使用されるかを定義する) の両方に定義されます。たとえば、「staff」というグループのメンバーシップに基本アクセス権を設定する場合、ACL コードは groupOf<anything> というオブジェクトクラスを持ち、CN が「staff」に設定されているオブジェクトを検索します。オブジェクトは、スタティックグループの groupOfUniqueNames のようにメンバーの DN を明示的に列挙するか、groupOfURLs のように LDAP URL を指定することによって、グループのメンバーを定義します。
グループオブジェクトは、objectclass = groupOfUniqueMembers と objectclass = groupOfURLs の両方を持つことができます。したがって、「uniqueMember」属性と「memberURL」属性のどちらも有効になります。グループのメンバーシップは、スタティックメンバーとダイナミックメンバーの和集合になります。
ダイナミックグループを使用すると、サーバーのパフォーマンスに影響があります。グループメンバーシップをテストするときに、DN がスタティックグループのメンバーではない場合、Web Server はデータベースのベース DN に含まれるすべてのダイナミックグループをチェックします。Web Server はこのタスクを実行するために、各 memberURL が一致するかどうかをチェックします。具体的には、そのベース DN とスコープに基づいてユーザーの DN をチェックしたあと、ベース DN としてのユーザー DN と memberURL のフィルタを使ってベース検索を実行します。この処理では、膨大な数の検索が行われることがあります。
新規のダイナミックグループを作成するために管理サーバーを使用するときには、次のガイドラインを考慮してください。
ダイナミックグループにほかのグループを含めることはできません。
グループの LDAP URL を次の形式で入力します (ホストとポートの情報は不要。これらのパラメータは無視される)。
ldap:///<base_dn>?<attributes>?<scope>?<(filter)>
必須パラメータについて、次の表で説明します。
<attributes>、<scope>、および <(filter)> パラメータは、URL 内での位置によって識別されます。どの属性も指定しない場合でも、疑問符を含めてそのフィールドを区切る必要があります。
オプションで、新しいグループの説明を追加することもできます。
定義済みの組織単位がディレクトリに存在している場合、「新規グループの追加先」リストを使って新しいグループの配置場所を指定できます。デフォルトの場所は、ディレクトリのルートポイント、つまり最上位のエントリです。