| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
多くの企業では、1つのエントリのユーザー・プロファイル、アクセス権および認証データなどのユーザー識別情報が、複数の場所の異種のデータ・ソースにわたって散在しています。たとえば、従業員情報はHR (人事管理)データベースやMicrosoft Active Directoryに保存され、顧客およびパートナ・データはCRM (顧客管理)データベースやその他のLDAPディレクトリに保存されています。企業は、様々なデータ・ソースからリアルタイムでユーザーのデータを集計する必要があります。この結果、識別データのコピーや同期を実行するアプリケーション専用のディレクトリが急激に増加しています。そして、これが高い管理コストや識別データの不統一および整合性の問題を引き起こしています。
Oracle Unified Directoryには、これらの課題に対応するディレクトリ・サービス・ソリューションが用意されています。Oracle Unified Directoryでは結合ワークフロー要素が新たにサポートされ、リポジトリの仮想ディレクトリ・ビューを表示したり、リポジトリとの間でデータをルーティングすることができます。
Oracle Unified Directoryでは、基盤となるデータ・リポジトリへ接続するProxyワークフロー要素などの、ワークフロー要素を定義します。また、結合ワークフロー要素を使用して、別のワークフロー要素のデータを結合し、カスタマイズしたディレクトリ・ツリーを表示することもできます。結合ワークフロー要素は、中間ファイルを作成することなく複数のデータ・ソースのデータを結合します。つまり、この処理は動的で、データ・ソース間の同期を必要としません。識別データを元の場所から移動することなく編成し、コピーすることなく識別データを再使用します。これにより、デプロイメントが簡単になり、コストが削減され、アイデンティティ・インフラストラクチャが単純になり、さらに定期的なアイデンティティ・ストアの変更にアプリケーションを合わせる必要がなくなるため投資回収率が向上します。
|
注意: なお、ディレクトリの仮想化では、仮想化環境でディレクトリ・サーバーが実行されない点に注意してください。 |
この章のこの項では、この仮想化ワークフロー要素について詳しく説明します。この項の内容は次のとおりです:
1つのエントリのデータが複数のデータ・ソースに分かれており、クライアントで様々なソースからのユーザーのデータをリアルタイムに集計する必要があるとします。
結合ワークフロー要素は、リレーショナル・データベースの表結合のように、複数の異なるデータ・ソースを統合された1つのLDAPビューに結合します。結合ワークフロー要素は、基盤となるデータ・リポジトリには接続しません。データを中間ファイルなしに集計するために、複数のプロキシ・ソースまたはローカル・バックエンドの最上位に構築されます。つまり、この処理は動的で、プロキシ・ソース間の同期を必要としません。結合ワークフロー要素は、ワークフロー要素間の結合の関係(ジョイナとも呼ばれます)を定義することにより複数のデータ・リポジトリを結合するものと考えることができます。ワークフロー要素は必要な数だけ構成できます。
結合ワークフロー要素の主要な目的は、LDAPクライアントにリアルタイムで集計データを提供することです。結合ワークフロー要素によって、1つのエントリの識別データが複数のディレクトリに保存されるというプロファイルの分裂の問題が解決されます。たとえば、結合ワークフロー要素を使用して、ユーザーのLDAPエントリと、人事管理データベース内のこのユーザーの役職をリンクさせることができます。
次に、結合ワークフロー要素の機能を示します。
結合ワークフロー要素は、中間ファイルを作成することなく複数の結合参加要素のデータを結合します。つまり、この処理は動的で、ソース間の同期を必要としません。
複数の参加要素の属性およびオブジェクトクラスを集計し、新しい仮想エントリを構成できます。
複雑な結合ルールによる、結合参加要素間の洗練された関係ツリーをサポートします。
任意の2つの参加要素間における関係を定義できます。1つのプライマリ参加要素と任意の数のセカンダリ参加要素をサポートします。
1つの参加要素から取得されたエントリごとに、結合ワークフロー要素は属性値joinedentrydnを追加します。これは、統合されたエントリの構成に使用されたセカンダリ参加要素からのエントリがどれかを示します。
プライマリ参加要素から取得されたエントリごとに、結合ワークフロー要素は結合されたエントリを構成するすべての関連するセカンダリ参加要素へ問い合せます。
参加するデータ・ソースから取得する属性と、保存する属性を指定できます。詳細は、第14.8項「属性フロー設定の処理」を参照してください。
有効に設定された操作をサポートします。詳細は、第14.12項「有効化された操作の管理」を参照してください。
バインドのフォールスルー機能がサポートされます。詳細は、第14.9項「バインド操作の処理」を参照してください。
書込み操作をカスケードできます。詳細は、第14.13項「セカンダリ参加要素への書き込み処理のカスケードの処理」を参照してください。
結合参加要素のクリティカル度を構成できます。詳細は、第14.11項「結合参加要素のクリティカル度の定義」を参照してください。
様々な結合シナリオに対応する1対1、多対1、シャドウなどの異なるジョイナ・タイプがサポートされます。詳細は、第14.6項「結合のタイプ」を参照してください。
各リポジトリ接尾辞から一般的な結合ワークフロー要素の接尾辞にわたって、DN構文の属性の翻訳をサポートします。詳細は、第14.10項「DN属性の翻訳の処理」を参照してください。
結合の参加要素にはワークフロー要素があり、統合済の結合エントリを構成する結合ワークフロー要素のいくつかの情報として使用されます。
たとえば、複数のディレクトリに分かれたユーザー情報を集計するように結合ワークフロー要素を構成できます。このシナリオでは、そのディレクトリから情報を取得するために、ディレクトリに関連付けられたプロキシ・ワークフロー要素を作成する必要があります。次に、結合ワークフロー要素の参加要素であるこのようなワークフロー要素を編成する必要があります。
結合ワークフロー要素には、1つ以上の参加データ・ソースがあり、それぞれがワークフロー要素を通じて公開されます。参加するワークフロー要素には、LDAPプロキシ・ワークフロー要素、ローカル・バックエンド・ワークフロー要素、分散ワークフロー要素、ロード・バランシング・ワークフロー要素、さらに別の結合ワークフロー要素などがあります。それぞれの参加するワークフロー要素は、結合参加要素と呼ばれます。
図14-1は、結合ワークフロー要素と参加しているワークフロー要素間の関係を示しています。
結合ワークフロー要素では、プライマリ参加要素を1つだけ使用でき、セカンダリ参加要素は使用しないか、1つ以上使用できます。プライマリ参加要素は、ディレクトリ・ツリー・エントリの作成および検索に使用されます。参加しているワークフロー要素の1つがプライマリ・ワークフロー要素として処理されます。この要素の、ディレクトリ情報ツリー(DIT)の構造は、デフォルトで結合ワークフロー要素によって公開されます。エントリは、結合ワークフロー要素から返されるために、そのエントリのプライマリ参加要素内に存在する必要があります。
管理者はプライマリとして処理される参加要素を決定します。結合ワークフロー要素は、プライマリ参加要素で検出された各エントリを取得し、定義された結合ルールに従って別の参加要素のエントリと結合することで動作します。
各参加要素には、接尾辞(DN)が1つ関連付けられます。これは、参加しているワークフロー要素または子のDNによって公開されるバックエンド・ネーミング・コンテキストと同じになる必要があります。結合ワークフロー要素にはDNが1つ関連付けられます。これは仮想DNであり、結合ワークフロー要素の関連付け先となるワークフローによって公開されます。したがって、管理者はクライアントに重要なディレクトリ・ツリーのみにビューを制限するように結合ワークフロー要素を構成できます。
結合ルールは、ある参加要素が他の参加要素とどのように関係するかを決定します。これは、結合ルールを指定するために不可欠です。結合ルールが定義されていない場合、LDAP操作の間にセカンダリ参加要素に問い合わせられなくなるためです。
|
注意: 結合ルールは常に2つの参加要素の関係のみを指定します。 |
結合ルールは、ある参加要素のエントリと他の参加要素のエントリ間の結合関係を指定します。結合ワークフロー要素は、セカンダリ参加要素に定義された結合ルールを基に、各セカンダリ参加要素を検索する検索フィルタを構成します。
結合ワークフロー要素には、セカンダリ参加要素ごとに結合ルールを構成します。これにより、その参加要素と他の参加要素のエントリ間の関係を指定します。結合ワークフロー要素が、関係ツリー全体にわたる移動をプライマリ参加要素から開始できるように、少なくとも1つのセカンダリ参加要素で指定された結合ルールがプライマリ参加要素と関係する必要があります。結合ルールは、セカンダリ参加要素にのみ定義し、プライマリ参加要素には定義できません。
結合ルールは、他の参加要素を検索して一致したエントリを取得するために、1つの参加要素のエントリの属性に特定します。次に、この一致したエントリが、結合エントリを構成するために、元のエントリと結合されます。一致した値が対象となるビューで検出されると、2つのエントリ間に結合が作成されます。
1つの参加要素から取得されたエントリごとに、結合ワークフロー要素は属性値joinedentrydnを追加します。これは、統合されたエントリの構成に使用されたセカンダリ参加要素からのエントリがどれかを示します。管理者は、この属性を移入するために、結合ワークフロー要素を構成する必要があると判断します。これは、結合の問題のトラブルシューティングを行うために役立つ場合があります。
Oracle Unified Directoryには、LDAPフィルタ結合ルールおよびDN結合ルールの2つのタイプの結合ルールが用意されています。結合ルールはすべてLDAPフィルタの構文に従います。このためANDやORを使用する複雑な結合ルールも可能です。
例:
(&(P1.userId = P2.uid)(|(P1.deptNumber = P2.department)(P1.empNum = P2.empId)))
|
注意: Shadowジョイナの場合、結合ルールは、プライマリおよびシャドウ参加要素の両方にある同じ属性に関連付ける必要があります。たとえば、 |
結合ルールは、常にセカンダリ参加要素で構成し、プライマリ参加要素では構成しません。次に有効な結合ルールの例を示します。
P2.commonName = P1.cn P3.dn = P2.dn (&(P4.cn= P3.cn)(P3.uid=P4.employeeid)) P1.uniquemember = P5.dn
結合ルールを定義する順序は関係ありません。たとえば、P1.cn=P2.commonnameは、P2.commonname=P1.cnと同じです。
次の項では、2つの結合ルールについて簡単に説明します。
属性ベースの結合ルールは、2つの参加要素の一致するエントリにある共通の属性値を基に、2つの参加要素間の結合関係を定義します。
たとえば、p1.uid=p2.usernameという結合ルールについて検討します。ここでp1とp2は2つの結合参加要素です。この結合ルールは、p1内のエントリについて、p1のエントリのuid属性値がp2のエントリのusername属性値と一致する場合、p2の対応する一致エントリが取得され、p1のエントリと結合されることを示します。uidが、p1内で複数の値を持つ属性の場合、p2への問合せ用検索フィルタの構成で、すべてのuid値の論理和がとられます。これはP2に送信される検索フィルタが次の形式になることを意味します。
(|(username=<uidvalue1>)(username=<uidvalue2>)) and so on
状況によっては、参加しているデータ・ソースに、エントリDN以外に共通の属性値がないことがあります。この場合、管理者はエントリDNに関連する結合ルールを構成できます。
DN結合ルールは、次のいずれかの形式にすることができます。
ある参加要素のエントリDNが、他の参加要素の属性と一致する。たとえば、このルールは次の構文を使用して構成できます。
P8.member = P7.dn
このDN結合ルールは、P8のメンバー属性値が、P7の一致するエントリの検出に使用される必要があることを要求します。
ある参加要素のエントリDNが、他の参加要素の属性と同じである。たとえば、このルールは次の構文を使用して構成できます。
P2.dn = P3.dn
この結合ルールはP2のエントリDNが、結合エントリを構成するためにP3のエントリDNと一致する必要があることを要求します。この場合、DN全体が異なっても、参加要素の接尾辞より下位のDNの部分が一致するエントリの検出に考慮されます。参加要素P2にdc=primary接尾辞があり、参加要素P3にdc=secondary接尾辞がある場合を考えます。この場合、前述の結合ルールは接尾辞よりも下位のツリーは同一であることを意味しています。このため、"uid=user.1,cn=users,dc=secondary"エントリは、"uid=user.1,cn=users,dc=primary"と関連付けられます。
図14-2は、結合ワークフロー要素と結合ルールを使用する結合参加要素の構成モデルを示しています。
Oracle Unified Directoryは、すべての参加している要素を同等に処理します。ただし、1つの参加要素をプライマリとして構成する必要があります。図14-2では、P1がプライマリ参加要素として構成されています。結合ルールをプライマリ参加要素に定義することは必須ではありません。
その他の参加要素のP2からP8はすべてセカンダリ参加要素です。セカンダリ参加要素にはそれぞれ、他の参加要素との関係を定義する結合ルールとジョイナ・タイプがあります。たとえば、P2の場合、P2.cn=P1.cnの結合ルールがP1との関係を定義し、P2で構成されたジョイナ・タイプが多対1の場合、P1からP2への関係は1対多であることを意味します。
参加要素P2、P8およびP5はプライマリ参加要素P1と直接関係し、その他のセカンダリ参加要素はプライマリ参加要素と間接的に関係しています。
ジョイナ・タイプは2つの参加要素間の結合関係を指定します。結合関係は2つの結合参加要素の接続方法を定義します。さらに、2つの結合参加要素の結合関係は、接続元の参加要素から接続先の参加要素へ導き、その接続方法を定義します。これらのジョイナ・タイプは、定義済、複雑または単純などのあらゆる結合ルールで機能します。
|
注意: P1からP2への結合関係が多対1のジョイナ・タイプで構成された場合、結合ワークフロー要素は逆の関係のP2からP1に1対多のジョイナ・タイプを内部で暗黙的に作成します。また、この逆の場合も同様です。1対1のジョイナとShadowジョイナの場合、逆の関係にも元の関係で構成されたジョイナ・タイプと同じものが含まれています。 |
次に、サポートされているジョイナ・タイプの説明を示します。
1対1のジョイナは、2つの参加要素のエントリ間での1対1の関係を定義します。1対1のジョイナ・タイプでは、接続元の参加要素の各エントリが、この関係の接続先の参加要素にある1つのエントリと対応します。接続先の参加要素に複数の一致するエントリが存在する場合、結合ワークフロー要素は、接続先の参加要素から結合のために最初に返されたエントリを使用します。
結合の基準には、LDAPフィルタ構文を使用し、ANDおよびOR条件を組み合せて、より複雑な結合基準を指定できます。例:
( & (P1.userId = P2.uid) ( | (P1.deptNumber = P2.department) (P1.empNum = P2.empId) ) )
このシナリオでは、複雑な結合基準の構成を基にした、セカンダリ参加要素に使用される検索フィルタが含まれています。プライマリ参加要素のエントリに、結合ルールに指定されたプライマリ属性のいずれかがない場合、結合は構成されません。
図14-3に、認証に使用される1対1のジョイナの高度な例を示します。
1対多のジョイナ・タイプでは、接続元の参加要素の各エントリが、この関係の接続先の参加要素にある複数のエントリと対応する場合、接続先のすべての一致するエントリが仮想結合エントリを構成する際に考慮されます。接続元参加要素のエントリに、接続先参加要素の対応するエントリが複数存在する状況はいくつかあります。このようなシナリオでは、1つの仮想エントリにそれらすべてのエントリを統合する必要があります。これにより、接続先参加要素のすべての一致するエントリが結合に含められます。
1対多の結合は、複数のロール・オブジェクトまたはIDを1つの仮想エントリに統合するときに役立ちます。
図14-4は、ポリシー・サーバーが、ある人のポリシーを決定するシナリオを表しています。統合を目的とする場合、ポリシー・サーバーは、権限属性として公開されているユーザーの権限が含まれる1つのエントリを認識することが望ましいとされます。これにより、ポリシー・サーバーは次の問合せで権限のアサーションをテストできます。
ldapsearch -b "uid=e027451,ou=People,o=LargeCo" -s base "(priv=XYZ Mgr)"
1対多ジョイナは、メインのou=Peopleエントリのプロファイル属性に基づいて、1つ以上の権限を1ユーザーと一致させるために使用されます。1対多ジョイナは、エントリと同じプロファイル値のすべての権限を検索して、それらをエントリとマージします。第2段階では、1対1の結合が使用され、Oracle Directory Server Enterprise Edition (ODSEE)の統合されたプロファイルがユーザーのActive Directory資格証明に使用されます。
多対1のジョイナ関係は、2つの参加要素間に多対1の関係を定義します。これは、1対多ジョイナ・タイプの逆です。接続元参加要素の複数エントリに、接続先参加要素の対応するエントリが1つ存在する状況はいくつかあります。
たとえば、プライマリ参加要素に従業員情報のリストがあり、セカンダリ参加要素に部署情報のリストがあるシナリオを考えます。複数の従業員が1つの部署に在籍している可能性があります。したがって、セカンダリ参加要素の1つの部門番号にプライマリ参加要素の複数の従業員が適用される可能性があります。プライマリ参加要素からある従業員が削除された場合、セカンダリ参加要素からその従業員の部門を削除する必要はありません。この削除のカスケードの問題に対応するには、1対多ジョイナ・タイプを使用してセカンダリ参加要素からプライマリ参加要素への関係を構成します。これにより、結合ワークフロー要素は内部で、プライマリ参加要素からセカンダリ参加要素への多対1ジョイナ関係を作成します。これは、参加要素のエントリを削除することで、セカンダリ参加要素の共有エントリが削除されることはないことを意味します。
LDAPアダプタやデータベース・ストアなどのソースでスキーマ拡張機能を必要とするが、スキーマ拡張機能がビジネスまたは技術的な理由により使用できない場合には、Shadowジョイナによってそれらのエントリを格納できます。Shadowジョイナでは、ローカル・バックエンド・ワークフロー要素などのその他のストアの拡張属性を格納できます。
Shadow結合関係は、プライマリ参加要素のエントリと同じ構造を維持しますが、別のソースを使用してシャドウ・エントリを作成することで追加の属性を保持します。Shadow結合関係を使用すると、アプリケーションで企業ディレクトリを使用し、アプリケーション固有の属性をローカル・バックエンド・ワークフロー要素などのシャドウ・ディレクトリに格納できます。アプリケーションは、すべての属性を格納するディレクトリと通信していると認識しますが、アプリケーション固有のデータは、Oracle Unified Directoryにより別のシャドウ・ディレクトリに透過的に格納されます。
Shadowジョイナは、すべてのプライマリ参加要素のDNをハッシュにエンコードすることで機能します。ハッシュはシャドウ参加要素の一致するエントリを検出するために使用されます。結合ワークフロー要素は、対応するレコードをシャドウ参加要素で見つけられないと、自動的に新しいレコードを作成し、指定の属性をシャドウ参加要素に格納します。Shadowジョイナ・タイプはアプリケーションに透過的に稼働し、プライマリ・ワークフロー要素のエントリと同期してエントリの作成や名前の変更を処理します。
Shadow結合では、すべてのLDAP操作がサポートされています。LDAP変更操作が行われると、Shadow結合はシャドウ参加要素の格納可能属性によって示されたパラメータを調査し、セカンダリ参加要素に格納する属性の有無を確認します。そのような属性が存在する場合、Shadow結合は、プライマリ・エントリのハッシュを使用して、ローカル・エントリの特定を試行します。特定されると、適切なLDAP変更操作がローカルで実行されます。ローカル・エントリが検出されない場合、Shadow結合は、プライマリDNが変更されている場合に備えて2回目の検索を実行し、プライマリ・キーを使用してエントリを特定します。ローカル・エントリが検出されない場合は、新しいエントリが自動的に作成されます。
|
注意: Shadowジョイナの場合、結合ルールは、プライマリおよびシャドウ参加要素の両方にある同じ属性に関連付ける必要があります。たとえば、 |
高可用性を実現するには、シャドウ・バックエンドにレプリケーションを構成する必要があります。
図14-5は、Oracle Unified Directoryへ接続するように構成された、CheckPointなどのファイアウォールを示しています。Oracle Unified Directoryは、ファイアウォール・スキーマを管理するためにローカル・バックエンド・データベースを使用します。これにより、企業ディレクトリ・スキーマをアプリケーション固有データで拡張することなく、企業エンタープライズ・ディレクトリへのファイアウォールの統合が可能になります。かわりに、Oracle Unified Directoryローカル・バックエンド・データベースにそれを格納することにより、ファイアウォール管理を担当するチームがアプリケーション固有データを管理できます。
条件付き結合は、結合が必要なエントリを制限するメカニズムで、条件を満たさないエントリは一切結合が行われることなく元の状態で返されます。結合条件は、LDAPフィルタ構文で指定します。たとえば、結合条件objectclass=inetorgpersonがプライマリ参加要素で定義されている場合、プライマリからのユーザー・エントリのみがその他の参加要素エントリと結合されます。プライマリからの非ユーザー・エントリは結合されることなく返されます。
結合条件は、ジョイナ・タイプがどのように構成されているかに関係なく、構成できます。
結合条件は、定義された参加要素に対して常に評価されます。多くの場合、この結合条件を定義するのはプライマリ参加要素内でのみ役に立ち、他の参加要素内では役に立ちません。
結合条件はORやANDを含んだ複雑なフィルタを使用して定義できます。例:
(&(employeenumber=101)(sn=Smith))
参加しているデータ・ソースには、そこから取得する属性と、保存する属性を指定するために権限があります。この権限を構成するには、参加しているワークフロー要素ごとに、格納可能および取得可能属性を構成します。
格納可能および取得可能属性は、結合参加要素との間の移入や移出方法を制御します。これらの設定により、認証されていないクライアントからの情報のリクエストや、そのようなクライアントに情報が戻されるのを防ぐことによりセキュリティを強化できます。さらに、結合ワークフロー要素の場合、複数の結合参加要素が同じ仮想結合エントリに寄与できるため、属性フロー設定によってどの属性がどの参加要素に流れるかを制御します。
|
注意: アクセス制御と違い、属性フロー設定は通知なしに適用されます。これは、この設定が単純に要求をフィルタし、エラーをクライアントに返すことがないことを意味します。セキュリティ性の高い環境では、この通知のない適用により、クライアント側では、特定の属性の表示が許可されているかどうかさえ知ることができません。 |
次に、属性フロー設定のリストを示します。次の各項では、それぞれの設定をさらに詳しく説明します。
取得可能な属性設定は、ターゲット・ディレクトリ上の結合参加要素で取得される属性を制御します。取得可能な属性設定は、検索および比較操作の間にプロキシ設定されたサーバーから指定された属性のみを取得できるため、サーバーのパフォーマンスや、場合によってはセキュリティの向上に貢献します。
さらに、結合ワークフロー要素の使用時に、取得可能な属性設定を使用して属性フローを制御できます。これは、結合ワークフロー要素が複数の参加要素のエントリを結合するためで、参加要素からの属性は制限する必要があります。結合ワークフロー要素の参加要素ごとに、結合ビューの参加要素からの属性のフローを制限するように取得可能な属性設定を構成する必要があります。
この設定を構成するには、「取得可能な属性」フィールドで、結合参加要素から取得できる属性の明示的なリストを指定する必要があります。リストが空の場合は、取得不可能な属性が定義されていないかぎり、すべての属性が取得可能です。「取得可能な属性」フィールドに指定されているリストは、リストに含まれている属性のみがプロキシ設定されたディレクトリからリクエストされることを示します。
属性は、たとえば次のシナリオのA1属性の場合に、取得できます。
取得可能なリストと取得不可能なリストが空の場合
取得可能なリストが空で、取得不可能なリストにA1が含まれていない場合
取得可能なリストにA1が含まれ、取得不可能なリストにA1が含まれていない場合
取得不可能な属性設定は、ターゲット・ディレクトリ上の参加要素で取得できない属性を制御します。リストが空の場合は、すべての属性が取得可能です。
格納可能な属性設定は、ターゲット・ディレクトリ上の参加要素で格納できる属性を制御します。格納可能な属性設定では、プロキシ設定されたサーバーに追加および変更の操作が送信されるのは指定された属性とその値のみであるため、サーバーのパフォーマンスや、場合によってはセキュリティの向上に貢献します。
さらに、結合ワークフロー要素の使用時に、格納可能な属性設定を使用して属性フローを制御できます。これは、結合ワークフロー要素が複数の参加要素のエントリを結合するためで、参加しているワークフロー要素への属性は制限する必要があります。結合ワークフロー要素の参加要素ごとに、結合ビューの参加要素からの属性のフローを制限するように格納可能な属性設定を構成する必要があります。
この設定を構成するには、「格納可能な属性」フィールドで、参加しているワークフロー要素に送信される必要がある属性の明示的なリストを指定する必要があります。リストが空の場合は、格納不可能な属性が定義されていないかぎり、すべての属性が格納可能です。属性は次のシナリオで格納できます。
格納可能なリストと格納不可能なリストが空の場合
格納可能なリストが空で、格納不可能なリストにその属性が含まれていない場合
格納可能なリストにその属性が含まれ、格納不可能なリストにその属性が含まれていない場合
格納不可能な属性設定は、変更できない属性を制御します。
結合ワークフロー要素は、任意の参加要素に対してユーザー認証をサポートします。結合ワークフロー要素のバインドのフォールスルー機能によって、複数のデータ・ソースに対するパスワード検証を試行できます。これは、ユーザーの識別情報が複数のディレクトリに存在し、パスワードが任意のデータ・ソースに格納されている可能性があるためです。したがって、ユーザーは1つのデータ・ソースだけで認証するのではなく、複数のデータ・ソースに対して認証する必要があります。
バインド機能を使用するには、バインドを該当する参加要素での有効な操作として構成する必要があります。結合ワークフロー要素の各参加要素には、ds-cfg-bind-priority構成パラメータがあり、バインドの処理において参加要素の優先度を決定します。
結合ワークフロー要素は、すべての参加要素に対してユーザー認証をサポートします。各参加要素には、バインドの優先度とバインド・フォールスルーが割り当てられ、すべてのバインド参加要素はバインドに成功するまでその順序で実行されます。バインドのエラーは、すべてのバインド参加要素が正常なユーザーの認証に失敗した場合にのみ返されます。
バインドの優先度は、ゼロ以上の任意の正の整数を指定できます。優先度は0(ゼロ)から高い整数値になるにつれて低くなります。つまり、最低の数の参加要素は、最高のバインドの優先度を持っていると見なされ、次に小さな数を持つものは次に高いバインドの優先度を持ち、それ以降も同様です。最も高い優先度はゼロです。
DN属性は、member、uniquemember、managerなど、ネームスペース変換が必要なDNとして処理される属性のリストです。たとえば、これらの属性がDN属性リストにある場合、プロキシ・ディレクトリからのグループ・エントリを読み取る際には、結合ワークフロー要素でuniquememberまたはmember属性だけでなく、グループ・エントリのDNが変換されます。
|
注意: クライアント・アプリケーションで必要とされる属性のみを変換します。すべての有効なDN属性を入力することが、アプリケーションで必要になる場合はないはずです。 |
クリティカル度構成によって、ホスト・エラーによって検索操作が失敗したときの結合ワークフロー要素の動作を指定します。クリティカル度は検索リクエストにのみ適用されます。書込み操作は、すべての参加要素で常に非クリティカルです。すべての参加要素でバインドや比較の操作も常に非クリティカルであるため、すべての適用可能な参加要素に、成功が検出されるまで、フォールスルーを実行できます。
クリティカル度は、結合参加要素にクリティカル度フラグを設定することによって構成できます。結合ワークフロー要素のクリティカル度の設定は、次のいずれかになります:
true
これはデフォルト設定で、対象の参加要素をクリティカルであると見なすことを示します。参加要素が操作エラーによって結果を返すことに失敗した場合、結合ワークフロー要素によって検索操作全体が失敗し、データが他の参加要素で見つかったかどうかにかかわらずDSA使用不可エラーがクライアントに返されます。
false
この設定は、参加要素での操作実行の失敗は全体的な結果にとってクリティカルではないことを結合ワークフロー要素に伝えます。クリティカル度の設定がfalseの場合、結合ワークフロー要素にクリティカルではない参加要素で操作の実行に失敗したことが伝えられます。次に、結果が単純にLDAP検索結果全体から単純に省略され、結合ワークフロー要素は、他の参加要素からの結果の一部を返し、エラーを通知しません。
Partial
この設定は、対象の参加要素が部分的にクリティカルであることを示します。これは、結果の一部が取得されたことをアプリケーションからアプリケーションのユーザーに通知できることを意味します。部分的にクリティカルな参加要素が、操作エラーによって結果を返すことに失敗した場合、結合ワークフロー要素は部分的な結果だけでなくAdmin Limit Exceededエラーも返します。これは、実際の内容とは異なるエラーですが、この設定の目的は、クライアント・アプリケーションのロジックによって、表示されている結果が全体の一部にすぎないことが示されることです。
結合参加要素のクリティカル度を設定するには、dsconfig set-join-participant-propサブコマンドを使用します。たとえば、次のコマンドでは、joinparticipant-1という名前のパーティションのクリティカル度がtrueに設定されます。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \ set-join-participant-prop --element-name we-join \ --participant-name joinparticipant-1 \ --set participant-criticality:true
結合参加要素で実行する操作は、ds-cfg-enabled-operationパラメータを使用して構成できます。参加要素は、このパラメータで指定されたLDAP操作のみに参加します。
デフォルトでは、参加要素は検索、比較、削除および変更の操作に参加します。参加要素が、バインド操作に参加するように、該当する参加要素でバインドを有効として構成する必要があります。バインド操作を有効として構成した場合、バインドの処理時に、構成されたバインドの優先度によって、参加要素の優先度が決定されます。このパラメータに指定できる値は次のとおりです。
検索
ADD
MODIFY
DELETE
MODIFYDN
BIND
COMPARE
セカンダリ参加要素に書き込み処理へのDELETEやMODIFYなどの書込み操作は、カスケードできます。これは、エントリがプライマリ参加要素から削除された場合、すべてのセカンダリ参加要素の関係するエントリも削除されます。ただし、これはDELETE操作が関連付けられたセカンダリ参加要素で有効な操作として構成されており、さらに元の参加要素とto-be-cascaded-delete参加要素が多対1ではない場合にのみ適用可能です。
MODIFY変更も、有効な操作の構成と、格納可能な属性の構成を基に、すべての適用可能なセカンダリ参加要素にカスケードされます。ADDおよびMODIFYDN変更も、セカンダリ参加要素での格納可能属性の構成を基に、シャドウセカンダリ参加要素にのみカスケードされます。
結合ワークフロー要素では、図14-6に示すとおり、バインド・リクエストを認証(Auth)プロバイダ・ワークフロー要素に委譲し、非バインド・リクエストをユーザー・プロバイダ・ワークフロー要素に委譲するように構成できます。また、この構成では、認証プロバイダ・ワークフロー要素へのMODIFY PASSWORDリクエストと、認証プロバイダ・ワークフロー要素へのその他のMODIFY操作を削除するにように指定できます。
単純なパススルー認証のシナリオでは、第12.7項「パススルー認証の理解」で説明されている、パススルー認証ワークフロー要素を使用してください。パススルー認証を結合ワークフロー要素で構成するのは、パススルー認証ワークフロー要素で満足できない特殊な要求がある場合のみにする必要があります。たとえば、パススルー認証ワークフロー要素がバインド・リクエストをユーザー・プロバイダ・ワークフロー要素にルーティングせず、ユーザー・パスワードが認証プロバイダ・ワークフロー要素にのみ格納される場合です。ユーザー・パスワードを認証プロバイダ・ワークフロー要素とユーザー・プロバイダ・ワークフロー要素の両方に格納する必要がある、異なるデプロイメントのシナリオが必要な場合は、結合ワークフロー要素を使用して、バインド・リクエストを処理するように両方のプロバイダを構成できます。
ある属性がプライマリおよびセカンダリ参加要素の両方に存在する場合、属性値が結合ワークフロー要素によってマージされます。読取り操作の場合、これは、すべての参加要素からの値を持つ複数値属性が返されることを意味します。書込み操作の場合、プロキシが、すべての参加要素に問い合わせて、結合参加要素のそれぞれで構成されている格納可能属性を基に、どこに値を書込むかを決定します。
|
注意: 次のことを念頭におく必要があります。
|
結合ワークフロー要素が様々なLDAP操作のために実行するプロセスを次の項で説明します。
格納可能な属性と有効な操作を基にプライマリ参加要素に対して処理されます。
構成されている格納可能な属性を基にシャドウセカンダリ参加要素のみに対して処理されます。
Shadowジョイナを除く他のジョイナの場合、セカンダリ参加要素に処理は実行されません。
DELETEが有効なすべての参加要素に対して処理されます。
多対1関係の一方である参加要素には処理されません。
格納可能な属性と有効な操作を基にプライマリ参加要素で処理されます。
セカンダリ(ジョイナ・タイプ)の場合、変更するアイテムの属性が格納可能な属性の場合、変更が実行されます。
Shadowジョイナの場合:
変更属性をシャドウ参加要素に格納する必要がある場合は、シャドウ・エントリが変更されます。
シャドウ・エントリがないときに、シャドウ参加要素に格納する必要がある場合は、変更属性を格納する新しいエントリを作成します。
|
注意: 異なるジョイナ・タイプのすべてのセカンダリ参加要素に対して、その参加要素の結合ルールで使用されているすべての属性は、リンクを維持するために暗黙的に格納不可として処理されます。このため、リンク属性の変更を結合ワークフロー要素によって行うことはできません。操作は成功しますが、リンク属性は変更されません。変更属性がリンク属性ではない参加要素が格納可能として定義されている場合は、すべて変更が実行されます。 |
有効な操作を基にプライマリ参加要素で処理されます。
Shadowジョイナの場合、結合ワークフロー要素はシャドウ・エントリDNを更新します。
他のジョイナ・タイプの場合、セカンダリ参加要素に処理は実行されません。
MODDNは、ジョイナがリンク属性用で、deleteoldrdnがtrueに設定されている場合、いずれのジョイナでも使用できません。
取得可能な属性と有効な操作を基にプライマリ参加要素で処理されます。
比較がプライマリ参加要素で失敗した場合、取得可能属性および有効な操作を基にすべてのセカンダリ参加要素でCOMPAREが処理されます。
バインドの優先度を基に各バインド参加要素で処理されます。
先に、プライマリ参加要素で処理されます。次に、結合条件を満足するプライマリ参加要素から返されたエントリごとに、該当するすべてのセカンダリ参加要素とエントリが結合されます。
|
注意: たとえば2つの異なるプロキシ・ワークフロー要素にある2つの |
dsconfigコマンドを使用した結合ワークフロー要素の作成と構成この項では、結合ワークフロー要素の作成および構成方法について説明します。この項の内容は次のとおりです:
結合ワークフロー要素を作成する前に、それぞれの参加要素に関連付けられたワークフロー要素を先に作成することをお薦めします。これにより、結合ワークフロー要素の構成が単純になります。
この項では、結合ワークフロー要素のトポロジの構成方法について説明します。
この項に示す結合ワークフロー要素を構成する手順は、それぞれの結合参加要素に必要なワークフロー要素を作成するための第14.16.1項「結合ワークフロー要素を作成するための前提条件」に記述されている基準を満たしていることが前提となります。
2つの個別のプロキシ・ワークフロー要素があるシナリオについて考えます。最初のプロキシ・ワークフロー要素we-proxy1は、結合ワークフロー要素の構成のプライマリ参加要素にリンクされます。2番目のプロキシ・ワークフロー要素we-proxy2は、結合ワークフロー要素の構成のセカンダリ参加要素にリンクされます。プロキシ・ワークフロー要素の作成の詳細は、第18.1.1.3.3項「プロキシLDAPワークフロー要素を作成するには」を参照してください。
we-proxy1データ・ソースには次のエントリがあると仮定します。
dn:cn=john,cn=users,dc=com1 objectclass:inetorgperson cn:john sn:doe uid:jdoe title:PMTS description: This entry is from we-proxy1
we-proxy2データソースには次のエントリが存在すると仮定します。
dn: sn=doe,cn=employees,dc=com2 empid: jdoe cn:John sn:doe department: Sales manager: userid=smith,cn=users,dc=com2 description: This entry is from we-proxy2 objectclass:inetorgperson
結合ワークフロー要素から返される結合済エントリは、次のようになります。
dn:cn=john,cn=users,dc=join objectclass:inetorgperson cn:john sn:doe uid:jdoe empid: jdoe title:PMTS description: This entry is from we-proxy1 description: This entry is from we-proxy2 manager: userid=smith,cn=users,dc=join department: Sales
この項で説明しているシナリオの場合、次の手順で結合ワークフロー要素トポロジを構成します。
we-joinという名前の結合ワークフロー要素を作成します。
dsconfig create-workflow-element --set enabled:true \ --set join-suffix:dc=join --type join --element-name we-join \
結合ワークフロー要素を作成するには、次の情報を指定する必要があります。
>>>> Specify Oracle Unified Directory LDAP connection parameters
Directory server hostname or IP address [ip]:
Directory server administration port number [4444]:
Administrator user bind DN [cn=Directory Manager]:
Password for user 'cn=Directory Manager':
>>>> Configure the properties of the Join Workflow Element
Property Value(s)
---------------------------------------------------------------
1) dn-attribute manager, member, memberof, uniquemember
2) enabled true
3) join-suffix dc=join
4) populate-joinedentrydn false
?) help
f) finish - create the new Join Workflow Element
q) quit
Enter choice [f]: f
The Join Workflow Element was created successfully
we-proxy1という名前のプロキシ・ワークフロー要素にリンクされたjp-p1という名前のプライマリ参加要素を作成します。
dsconfig create-join-participant --element-name we-join \ --set participant-dn:dc=com1 \ --set participating-workflow-element:we-proxy1 \ --set primary-participant:true --type generic --participant-name jp-p1 \
プライマリ参加要素を作成するには、次の情報を指定する必要があります。
>>>> Specify Oracle Unified Directory LDAP connection parameters
Directory server hostname or IP address [ip]:
Directory server administration port number [4444]:
Administrator user bind DN [cn=Directory Manager]:
Password for user 'cn=Directory Manager':
>>>> Configure the properties of the Join Participant
Property Value(s)
----------------------------------------------------------------------
1) enabled-operation compare, delete, modify, search
2) join-condition By default, no join condition is
defined. That is all entries
satisfying the original search filter
are considered for join.
3) joiner-type one-to-one
4) non-retrievable-attribute By default, the non-retrievable list
is empty, which means that all
attributes are retrievable.
5) non-storable-attribute By default, the non-storable list is
empty, which means that all attributes
are storable.
6) participant-bind-priority 0
7) participant-criticality true
8) participant-dn dc=com1
9) participants-join-rule ""
10) participating-workflow-element we-proxy1
11) primary-participant true
12) retrievable-attribute By default, the retrievable list is
empty, which means that all attributes
are retrievable.
13) storable-attribute By default, the storable list is
empty, which means that all attributes
are storable.
?) help
f) finish - create the new Join Participant
q) quit
Enter choice [f]: f
The Join Participant was created successfully.
we-proxy2という名前のプロキシ・ワークフロー要素にリンクされたjp-p2という名前のセカンダリ参加要素を作成します。
dsconfig create-join-participant --element-name we-join \ --set participant-dn:dc=com2 \ --set participating-workflow-element:we-proxy2 \ --set primary-participant:false --type generic --participant-name jp-p2 \ --set participants-join-rule:jp-p1.uid=jp-p2.empid
セカンダリ参加要素を作成するには、次の情報を指定する必要があります。
>>>> Specify Oracle Unified Directory LDAP connection parameters
Directory server hostname or IP address [ip]:
Directory server administration port number [4444]:
Administrator user bind DN [cn=Directory Manager]:
Password for user 'cn=Directory Manager':
>>>> Configure the properties of the Join Participant
Property Value(s)
----------------------------------------------------------------------
1) enabled-operation compare, delete, modify, search
2) join-condition By default, no join condition is
defined. That is all entries
satisfying the original search filter
are considered for join.
3) joiner-type one-to-one
4) non-retrievable-attribute By default, the non-retrievable list
is empty, which means that all
attributes are retrievable.
5) non-storable-attribute By default, the non-storable list is
empty, which means that all attributes
are storable.
6) participant-bind-priority 0
7) participant-criticality true
8) participant-dn dc=com2
9) participants-join-rule jp-p1.uid=jp-p2.empid
10) participating-workflow-element we-proxy2
11) primary-participant false
12) retrievable-attribute By default, the retrievable list is
empty, which means that all attributes
are retrievable.
13) storable-attribute By default, the storable list is
empty, which means that all attributes
are storable.
?) help
f) finish - create the new Join Participant
q) quit
Enter choice [f]: f
The Join Participant was created successfully.
