グループとロールのメカニズムは、一部の機能が重なっています。どちらのメカニズムにも利点と欠点があります。一般に、ロールメカニズムのほうが、頻繁に必要となる機能を効率的に提供できるように設計されています。グループ化メカニズムはサーバーの複雑さに影響を及ぼし、グループ化メカニズムを選択することで、クライアントがどのようにメンバー情報を処理するかが決まるため、グループ化メカニズムは慎重に計画する必要があります。どちらのメカニズムがより適しているかを判断するには、実行する標準的なメンバーシップクエリーと管理操作を理解してください。
グループには、次の利点があります。
スタティックグループは、標準に準拠した唯一のグループ化メカニズムである。そのため、スタティックグループは、ほとんどのクライアントアプリケーションおよび LDAP サーバーと相互運用できます。
メンバーを列挙するには、ロールよりスタティックグループの方が適している。
特定のセットのメンバーを列挙するだけでよい場合は、スタティックグループの方がコストが低くなります。member 属性を取得してスタティックグループのメンバーを列挙することは、同じロールを共有するすべてのエントリを調べるより簡単です。Directory Server 6.1 では、多くの値を持つ複数値属性に対して大幅なパフォーマンス強化が実現されています。特にスタティックグループとの関連では、これらの属性に対する等価照合や変更操作が大幅に機能強化されています。また、グループエントリに対するメンバーシップのテストも機能強化されています。これらの機能強化によって、スタティックグループに対して以前あった制限の一部 (特にグループサイズに対する制限) が解消されています。
また、Directory Server 6.1 では isMemberOf オペレーショナル属性をユーザーエントリに直接指定することで、そのユーザーがどのグループのメンバーであるかを明示できます。この機能はスタティックグループのみに適用されますが、入れ子のグループも含まれます。詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「グループの管理」を参照してください。
メンバーの割り当てや削除などの管理操作には、ロールよりスタティックグループが適している。
スタティックグループは、ユーザーをセットに割り当てたり、ユーザーをセットから削除したりするためのもっとも単純なメカニズムです。ユーザーをグループに追加するために、特殊なアクセス権は必要ありません。
グループエントリを作成する権限があると、そのグループにメンバーを割り当てる権限が自動的に与えられます。これは、管理されているロールやフィルタを適用したロールには当てはまりません。これらのロールでは、管理者が、ユーザーエントリに nsroledn 属性を書き込むための権限も持っている必要があります。アクセス権に関する同じ制約が、入れ子のロールにも間接的に適用されます。入れ子のロールを作成するには、入れ子の対象となるすでに定義されているほかのロールに対する権限が必要となります。
フィルタベースの ACI で使用するには、ロールよりダイナミックグループが適している。
ACI でのバインドルールの指定など、フィルタに基づいてすべてのメンバーを検索するだけの場合は、ダイナミックグループを使用します。フィルタを適用したロールはダイナミックグループと似ていますが、ロールメカニズムを起動して nsRole 仮想属性を生成します。クライアントが nsRole 値を必要としない場合は、ダイナミックグループを使用してこの計算のオーバーヘッドを回避します。
既存のセットに対してセットの追加や削除を行うときは、ロールよりグループが適している。
あるセットを既存のセットに追加したり、あるセットを既存のセットから削除する場合は、グループメカニズムがもっとも単純です。グループメカニズムには、入れ子の制限がありません。ロールメカニズムでは、他のロールを受け入れられるのは入れ子のロールに限られています。
エントリのグループ化範囲の柔軟性が重要になる場合は、ロールよりグループが適している。
グループのメンバー範囲は、グループ定義エントリの場所に関係なくディレクトリ全体であるため、範囲の面ではグループには柔軟性があります。ロールでも、特定のサブツリーを超えて範囲を拡張することができますが、入れ子のロールに範囲拡張属性 nsRoleScopeDN を追加することでしか実現できません。
ロールには、次の利点があります。
セットのメンバーを列挙し、かつ特定のエントリがメンバーになっているすべてのセットを検索する場合は、ダイナミックグループよりロールの方が適している。スタティックグループでも、isMemberOf 属性によってこの機能を提供しています。
ロールはメンバーシップ情報をユーザーエントリにプッシュします。そこでこの情報をキャッシュできるので、以後のメンバーシップのテストをより効率的に行えます。サーバーがすべての計算を実行し、クライアントは nsRole 属性の値を読み取るだけです。さらに、この属性にすべてのタイプのロールが含まれ、クライアントはすべてのロールを均等に処理できます。ダイナミックグループよりもロールの方が、両方の処理をより効率よく実行でき、クライアント側での処理が簡単になります。
CoS、パスワードポリシー、アカウントの無効化、ACI など、Directory Server の既存の機能とグループ化メカニズムを統合する場合は、グループよりロールが適している。
セットのメンバーシップをサーバーで「自然に」使用する場合は、ロールの方が優れたオプションです。ロールを利用するということは、サーバーが自動的に実行するメンバーシップの計算方法を使用することを意味します。ロールは、リソース指向の ACI で、CoS のベースとして、より複雑な検索フィルタの一部として、さらにパスワードポリシーやアカウントの無効化などに使用することができます。グループを使用してこのような統合を行うことはできません。
ロールを使用する場合は、次の問題に注意してください。
nsRole 属性を割り当てることができるのはロールメカニズムだけです。この属性は、どのディレクトリユーザーも割り当てたり、変更したりできませんが、どのディレクトリユーザーも「読み取れる」可能性があります。この属性が、不正なユーザーから読み取られないようにするには、アクセス制御を定義してください。
nsRoleDN 属性は、管理されているロールのメンバーシップを定義します。ユーザーがロールに自分自身を追加したり削除したりできるかどうかを決定してください。自分のロールを変更できないようにするには、そのための ACI を定義してください。
フィルタを適用したロールは、ユーザーエントリ内の属性の存在または値に基づくフィルタを介してメンバーシップを決定します。フィルタを適用したロール内のメンバーシップを定義できるユーザーを制御するには、これらの属性のユーザーアクセス権を慎重に割り当ててください。