| Oracle® Fusion Middlewareテクノロジ・アダプタの理解 12c (12.2.1.3.0) E90274-03 |
|
 前 |
 次 |
図12-1は、Oracle LDAPアダプタがCRUD操作の実行に使用できる同期/非同期サービス・インタフェースをターゲット・ディレクトリ・サーバーに公開する方法を示しています。ここでは、Oracle LDAPアダプタがソース・ディレクトリ・サーバーからの変更イベントをポーリングして、公開サービスとして使用できるようにこれらのイベントをパブリッシュする方法を示しています。また、LDAPアダプタは、DSMLv2リクエストを受け取ってターゲット・ディレクトリ・サーバーで実行し、DSMLv2レスポンスを返す、DSML同期サービスも提供します。
LDAPアダプタは、SOA SCA環境でのLDAPサーバーの構成とLDAPサーバーへの接続のための拡張ソリューションを提供します。ランタイム・コンポーネントでは、外部LDAPサーバーへの物理的な接続を提供します。これは参照として機能し、LDAPサーバーへのリクエストを送信するアウトバウンド・サービスをサポートします。また、LDAPサーバーで変更イベントをポーリングするインバウンド・サービスをサポートするサービスとしても機能します。
この章の内容は次のとおりです。
LDAP (Lightweight Directory Access Protocol)は、情報ディレクトリにアクセスするためのインターネット・プロトコルです。ディレクトリ・サービスとは、エントリと属性をディレクトリ内で管理するように設計された分散データベース・アプリケーションです。LDAPは、TCP/IP経由で実行されます。LDAPを使用すると、クライアントはエントリに基づいて様々なディレクトリ・サービスにアクセスできます。これにより、エントリおよびその属性は、アクセス制御に基づいてユーザーや他のアプリケーションに対して使用可能になります。
Oracle Adapter for LDAPは、LDAPv3定義の操作に対する豊富なサポートおよび拡張機能のサポートを提供しています。また、DSMLv2もサポートされているため、DSMLゲートウェイ・サービスとして使用できます。ソース・ディレクトリ・サーバーからの変更イベントをリスニングしてパブリッシュするようにアダプタを構成できます。また、アダプタでは、1回かぎりのメッセージ配信、高可用性、ポリシー・ベースの再試行とフォルト処理、自動フェイルオーバー、およびその他のいくつかの機能も保証しています。
LDAPディレクトリには、エンティティに関連する情報を含むエントリが含まれます。エントリの各属性には、1つの名前と1つ以上の値が存在します。属性の名前は、一般名がcn、電子メール・アドレスがmailのように、一般的にニーモニック文字列となります。たとえば、ある会社が従業員ディレクトリを所有しているとします。この従業員ディレクトリの各エントリは従業員を表しています。従業員エントリには、名前、電子メール・アドレス、電話番号などの情報が含まれます。次の例を参照してください。
cn: John Doe mail: johndoe@mydomain.com mail: jdoe@mydomain.com telephoneNumber: 471-6000 x.1234
記述情報のそれぞれの部分(従業員の名前など)は、属性と呼ばれます。例では、一般名(cn)属性が従業員の名前を表しています。この他に、mail属性とtelephoneNumber属性があります。
各属性には1つ以上の値が存在します。たとえば、1つの従業員エントリに、johndoe@mydomain.comおよびjdoe@oracle.comの値を持つmail属性が含まれることがあります。前述の例では、mail属性に2つのmail値が含まれています。
ディレクトリの編成はツリー構造になっています。ディレクトリ内の最上位のエントリは、ルート・エントリと呼ばれます。このエントリは通常、ディレクトリを所有する組織を表します。
階層レベルが高いエントリほど、大きいグループまたは組織を表します。大きい組織より下のエントリは、その大きい組織を構成する小さい組織を表しています。
ツリー構造のリーフ・ノード(エントリ)は、個々の個人またはリソースを表しています。
エントリは属性の集合で構成され、これらの属性は識別名(DN)と呼ばれる一意の識別子を持ちます。DNは、その階層レベルでエントリを一意に識別する名前です。
次の例では、John DoeとJane Doeは、同じレベルにある異なるエントリを識別する別々の一般名(cn)です。
また、DNは、エントリをツリーのルートまで遡ってトレースする名前の完全修飾パスでもあります。たとえば、John Doeエントリの識別名は次のようになります。
cn=John Doe, ou=People, dc=mydomain.com
相対識別名(RDN)は、識別名のコンポーネントです。たとえば、cn=John Doe, ou=Peopleは、ルートRDN dc=mydomain.comに対するRDNです。
DNはエントリの完全修飾パスを記述するために使用し、RDNはツリー内の別のエントリを基準にしたエントリのパスの一部を記述するために使用します。図12-2に、識別名と相対識別名を含むLDAPディレクトリ構造の例を示します。
ディレクトリ・サービスとは、エントリと属性をディレクトリ内で管理するように設計された分散データベース・アプリケーションです。また、ディレクトリ・サービスは、エントリおよび属性をユーザーや他のアプリケーションに対して使用可能にします。Oracle Internet Directoryサーバーは、ディレクトリ・サービスの一例です。他に、Oracle Directory Server Enterprise EditionやMicrosoft Active Directoryなどのディレクトリ・サービスがあります。
ディレクトリ・クライアントは、LDAPプロトコルを使用してディレクトリ・サービスにアクセスします。ディレクトリ・クライアントは、ディレクトリ・サービスにアクセスするために、使用可能なクライアントAPIのいずれかを使用できます。
Oracle LDAPアダプタAPIは、未指定のリフェラル基準に基づいて検索結果を問い合せます。検索結果には多数のリフェラルが含まれることがあります。リフェラルとは、クライアントのリクエストを別のサーバーにリダイレクトするために使用されるエンティティです。リフェラルには他のオブジェクトの名前と場所が含まれています。
たとえば、LDAPサーバーは、クライアントがリクエストした情報が別の場所(別のサーバーまたは複数のサーバーなど)に見つかる可能性があることを示すために、クライアントにリフェラルを送信します。
リフェラルには、実際のエントリが存在するLDAPサーバーのURLが含まれます。LDAP URLには、サーバーのホスト/ポートおよびオブジェクトのDNが含まれます。
コントロールは、LDAPで既存の操作を拡張するためのメカニズムを提供します。LDAPアダプタでは、コントロールをリクエスト操作とともに渡すことができます。
コントロールを操作リクエスト・メッセージとともに含めると、コントロール情報を使用して、操作の処理方法に関する追加情報を指定できます。
リクエスト・コントロールの形式は、name-criticality-valueのタプルです。
requestControls="controlName1|controlOID:criticality:prop1:value1:prop2:value2;
controlName|controlOidは、リクエスト操作とともに渡す必要のあるコントロールの一意の名前/OIDです。
criticalityは、リクエストとともに渡されたコントロールがターゲット・ディレクトリ・サーバーでサポートされていない場合の動作を指定するブール属性です。オプションで、リクエスト・コントロールに渡すことができる値を表す値文字列を指定できます。
LDAPアダプタでLDAPコントロールを使用する際には、いくつかの制限事項があります。
criticalityをtrueとしてサポート対象外のコントロールを使用すると、例外が発生し、ターゲット・ディレクトリ・サーバーでLDAP操作は実行されません。
操作に適用可能なコントロールのみが実行されます。適用可能でないコントロールが操作とともに渡された場合、そのコントロールは無視されます。
1つの操作にのみ適用可能なコントロールもあれば、複数の操作に関連するコントロールもあります。たとえば、subtreeDeleteRequestControlは削除操作にのみ適用可能ですが、assertionRequestControlはすべての操作に適用可能です。
LDAPアダプタが認識できないコントロールは汎用として処理されます。このようなコントロールの動作は明確に定義されていません。
リクエスト・コントロールのみがサポートされています。LDAPアダプタでは、レスポンス・コントロールはサポートされていません。
ディレクトリ・サーバー、コントロールおよびLDAPアダプタ操作のリストは、表12-1を参照してください。
表12-1 サポートされているディレクトリ・サーバー・コントロールおよびLDAPアダプタ操作
| 操作 | コントロール(名前) | コントロール(OID) | Microsoft Active Directory | ODSEE (Oracle Directory Server Enterprise Edition) | OID |
|---|---|---|---|---|---|
検索 |
ManageDsaITRequestControl |
2.16.840.1.113730.3.4.2 |
非サポート |
サポート |
サポート |
[-] |
ServerSideSortRequestControl |
1.2.840.113556.1.4.473 |
サポート |
サポート |
サポート |
[-] |
GetEffectiveRightsRequestControl |
1.3.6.1.4.1.42.2.27.9.5.2 |
非サポート |
サポート |
非サポート |
[-] |
MatchedValuesRequestControl |
1.2.826.0.1.3344810.2.3 |
非サポート |
非サポート |
非サポート |
[-] |
[-] |
[-] |
[-] |
[-] |
[-] |
削除 |
SubtreeDeleteRequestControl |
1.2.840.113556.1.4.805 |
サポート |
非サポート |
非サポート |
[-] |
[-] |
[-] |
[-] |
[-] |
[-] |
変更 |
PermissiveModifyRequestControl |
1.2.840.113556.1.4.1413 |
サポート |
非サポート |
非サポート |
[-] |
[-] |
[-] |
[-] |
[-] |
[-] |
DNの変更 |
ウィザードに表示されるコントロールはありません。 |
[-] |
[-] |
[-] |
[-] |
LDAPアダプタ構成ウィザードでは、操作とともにリクエスト・コントロールを添付できます。「コントロールの添付」画面の動作は次のとおりです。
デフォルトでは、操作に適用可能な、接続先のディレクトリ・サーバーでサポートされているコントロールのみがウィザードに表示されます。
例: 削除操作に適用可能なコントロールはassertionRequestおよびSubtreeDeleteですが、ターゲット・ディレクトリ・サーバーでサブツリー削除操作がサポートされていない場合、assertionRequestのみが表示されます。
サポートされている他のコントロールを追加するように選択できます。これらのコントロールは汎用として処理されますが、これらのコントロールの実行時動作は明確に定義されていないため、これらのコントロールを十分にテストする必要があります。
「LDAPブラウザ」ページを使用して、ディレクトリ情報ツリー(DIT)を表示します。このブラウザは、LDAPアダプタ構成ウィザードで「参照」を選択すると呼び出されます。図12-3を参照してください。
エントリを選択するには、DIT内のエントリを選択し、「OK」ボタンをクリックします。選択したエントリは、LDAPアダプタ構成ウィザードで以降に実行する検索操作やエントリ変更通知操作でベースDNとして使用したり、追加操作でテンプレートとして使用します。
あるアイテムに関連する属性を表示するには、選択したエントリをダブルクリックします。
属性ビューアが2列のレイアウトで表示されます。左側の列には属性の説明(または名前)が含まれ、右側の列には属性値が含まれます。各行は名前と値のペアを表しています。直前のセクションの属性表に、現在のエントリの識別名が表示されます。図12-4を参照してください。
LDAPディレクトリのディレクトリ情報ツリーは、固有の階層構造で表示されます。階層の第1レベルにはベース・エントリが含まれます。エントリを展開すると、その直接の子がディレクトリからフェッチされます。ディレクトリの参照中、LDAPブラウザはフェッチされたエントリに子があるかどうかを調べます。子のないエントリは展開できません。
デフォルトでは、大きな参照結果は、それぞれ100個のエントリからなる仮想フォルダに折りたたまれます。このため、表示されるツリーは比較的小さくなります。パフォーマンスを向上させるため、フェッチされるアイテムの数は1000アイテムに制限されます。レコードが1000を超えるフォルダを操作する場合は、検索操作を使用できます。図12-5を参照してください。
ブラウザで必要なエントリがロードされない場合は、代替アプローチとして検索操作を使用できます。1つの検索属性および値を指定することにより、DITを検索できます。検索はサブツリー全体にわたって処理されます。検索結果の量に関する制限はありません。
左側のコンボ・ボックスで、よく使用される属性のリスト(cn、givenName、mail、member、objectClass、sn、telephoneNumber、uniqueMember)から検索属性を選択できます。
グループであるエントリにわたって検索を処理することを指定するには、オプション「グループ」を使用します。
個人、アカウントまたはユーザーであるエントリにわたって検索を処理することを指定するには、オプション「ユーザー」を使用します。
右側の入力フィールドに検索値を入力します。必要に応じて、ワイルドカードとして'*'を使用します。
検索操作を開始するには、右側にある緑色の三角形ボタンを選択します。左側のコンボ・ボックスで「FilterType.LDAPFilter」を選択して、右側のフィールド内に手動でLDAP検索フィルタを設定します。
LDAPプロトコルおよびLDAPアダプタは、ディレクトリ情報への高速な読取りアクセスを提供します。
この項で詳しく説明するように、LDAPアダプタではインバウンド・メッセージとアウトバウンド・メッセージの両方がサポートされており、次の機能が組み込まれています。
注意:
LDAPアダプタでは、アウトバウンド・メッセージに対するトランザクション・サポートを提供していません。
LDAP構成ウィザードを使用してLDAPアダプタを構成し、コンテキスト・メニューからオプションを選択したり、LDAPディレクトリ・スキーマを参照することにより、LDAPサービスをモデル化します。LDAPアダプタ・ウィザードでは、ターゲットLDAPディレクトリ・サーバーへの接続が必要であり、その構成方法は次のとおりです。
表12-2に、LDAPアダプタのJNDI接続プール・プロパティを示します。
表12-2 LDAPアダプタのJNDI接続プール・プロパティ
| プロパティ名 | 説明 | デフォルト | 必須 |
|---|---|---|---|
|
ディレクトリ・サーバーにバインドする必要のある識別名。例: cn=orcladmin |
cn=Directory Manager |
はい(匿名以外の認証方式を使用する場合に必要です。) |
|
ディレクトリ・サーバーのホスト名。 |
localhost |
はい |
|
有効なXAデータソースを指すJNDI文字列の場所。例: jdbc/SOADataSource |
なし |
はい(インバウンド方向でLDAPアダプタを使用する必要がある場合) |
|
操作のタイムアウトを設定します。レスポンスがタイムアウト期間にディレクトリ・サーバーから受信されない場合、操作は中止され、例外が発生します。例: 1000 |
False |
いいえ |
password |
ディレクトリ・サーバーのパスワード。 |
welcome |
はい(匿名以外の認証方式を使用する場合に必要です。) |
|
ディレクトリ・サーバーが稼働しているポート。 |
389 |
はい |
hostName |
ディレクトリ・サーバーのホスト名。 |
Localhost |
はい |
port |
LDAPサービスが実行されているポート。 |
389 |
はい |
|
SecurityProviderはSSLコンテキストで使用されるプロバイダURLです。例: ldaps://myhost.example.com:636 |
なし |
いいえ |
|
キー管理プロトコル。例: SSLl |
なし |
いいえ。useSSLまたはstartTLSを選択した場合のみ必須です。 |
|
trueに設定した場合、クライアントは、サーバーが提示する証明書を無条件に信頼します。 |
ture |
いいえ。useSSLまたはstartTLSを選択した場合のみ必須です。サーバー証明書をトラスト・ストアで検証する必要がある場合は、falseに設定します。 |
trustStorePassword |
トラスト・ストアのコンテンツにアクセスするために必要なパスワードを指定します。 |
なし |
いいえ |
|
クライアントがサーバー認証に使用するトラスト・ストア・ファイルへのファイル・システム・パスを指定します。 |
false |
いいえ。SSLまたはstartTLSを使用する場合のみ必須です。 |
|
Javaプロバイダ名。例: JKS |
なし |
いいえ、SSLまたはstartTLSを使用する場合のみ必須です。 |
|
セキュアなチャネルを確立する必要があるかどうかを指定します。 |
False |
いいえ |
|
プレーンな非SSL接続において、後でセキュアな接続のためにstartTLSを有効にする場合に指定します。 |
False |
いいえ、useSSLがtrueに設定してある場合はtrueに設定しません。これは非SSLプレーン・ポートをサーバー接続に使用する場合に有効にする必要があります。 |
注意:
デフォルト値をサポートされているターゲット・ディレクトリ・サーバーのインストールから取得した実際の値と置き換え、最新のデプロイメント・プランでLdapAdapterを再デプロイします。LDAPアダプタでは、LDAPアダプタからの次のアウトバウンド操作をサポートしています。
追加
削除
変更
DNの変更
比較
検索
DSML
注意:
LDAPアダプタでは、アウトバウンド操作に対するトランザクション・サポートを提供していません。追加操作では、特定のDNおよび一連の属性を持つエントリを追加します。追加するエントリがすでに存在する場合や、指定された操作を完了できなかった場合は、エラーが返されます。
LDAP構成ウィザードの追加操作を使用するには、次の手順を実行します。
LDAPの削除操作では、特定のDNを持つエントリを削除します。オプションで、LDAP削除リクエストとともにコントロールを追加できます。削除操作では、指定されたエントリを削除できない場合やエントリが存在しない場合、エラーが返されます。また、リクエスト・メッセージに添付されたクリティカル・コントロールがターゲット・ディレクトリ・サーバーでサポートされていない場合にもエラーが返されます。
削除操作を使用するには、次の手順を実行します。
「コントロールの添付」画面では、削除操作に対して追加の制約を提供するためのコントロールを添付できます。コントロールを添付するか、「次へ」をクリックできます。LDAPアダプタとターゲット・ディレクトリ・サーバーでサポートされているコントロールを添付する場合は、「添付」チェック・ボックスを選択して、削除要求操作とともにコントロールを組み込みます。コントロールの詳細は、「LDAPアダプタ構成」の「コントロール」の項を参照してください。
図12-10 LDAP構成ウィザードの削除操作の「コントロールの添付」画面で追加された削除コントロール
LDAPの変更操作では、ディレクトリ・サーバーの既存のエントリを変更します。
変更で実行できる変更のタイプは、「追加」、「削除」および「置換」です。
追加: 属性が存在しない場合は属性を作成し、指定した値を追加します。属性がすでに存在する場合、指定した値が属性値に追加されます。追加操作では少なくとも1つの値が存在する必要があり、また属性のすべての値が一意である必要があります。
削除: 指定した値を属性から削除します。値が指定されていない場合、または属性のすべての既存値が指定されている場合、その属性は削除されます。必須の属性を削除することはできません。
置換: 必要に応じて属性を作成し、属性のすべての既存値を指定した値で置き換えます。複数の値を持つ属性の既存の値を保持する場合は、それらの値を置換操作で指定する必要があります。値を指定せずに置換操作を実行すると、属性が存在していれば属性全体が削除され、属性が存在していなければ無視されます。すべての操作が成功するまで、ディレクトリに対する変更は行われません。変更中に接続が失敗した場合、変更が行われたかどうかは予測できません。
LDAP構成ウィザードの変更操作を使用するには、次の手順を実行します。
「操作タイプ」画面で、「変更」操作を選択します。「変更」操作画面が表示されます。
このページで、「オブジェクト・クラス」のリストから選択します。変更する属性の「選択可能」リストから、変更可能な属性を選択して「選択済」に移動します。左矢印キーを使用して、選択済リストから削除することもできます。「次へ」をクリックします。
「コントロールの添付」ページが表示されます。図12-12を参照してください。
緑色の＋を使用して、カスタム・コントロールか、ターゲット・ディレクトリ・サーバーで提供されているコントロールを追加します。次に例を示します。必要なコントロールを選択し、「値」列に値を入力して指定します。
注意:
サポートされているコントロールについては、ターゲット・ディレクトリ・サーバーのドキュメントを参照してください。コントロールを添付する前に、この章の関連操作を確認してください。ターゲット・ディレクトリ・サーバーでサポートされているすべてのコントロールがLDAPアダプタでサポートされているとはかぎりません。
「次へ」をクリックします。変更の「終了」画面に、LDAPサービスのWSDLファイル、xsdファイルおよびjcaファイルの名前が表示されます。
LDAPのDNの変更操作は、ディレクトリ・サーバーのエントリの識別名を変更するために使用できます。また、エントリのRDNを変更したり、エントリを新しい親の下に移動できます。ターゲット・エントリが下位エントリを保有する場合は、サブツリーの移動または名前の変更に使用する場合があります。
DNの変更操作を使用するには、次の手順を実行します。
コントロールを添付するように選択した場合は、次のようなページが表示されます。
図12-15では、新しいカスタム・コントロールとディレクトリ・サーバーで使用可能なコントロール("MatchedValues...")と一致するコントロールの両方がコントロールとして追加されています。
LDAPの比較操作では、指定したエントリに特定の属性値が含まれるかどうかを判別します。
LDAPアダプタの比較操作を使用するには、次の手順を実行します。
LDAPアダプタの検索操作は、ディレクトリ・サーバーで特定の基準セットに一致するエントリを特定するために使用できます。0個以上のエントリ、また0個以上のリフェラルを返す場合があります。検索操作では次の基準が使用されます。
ベースDN: 検索を実行するDIT内の位置を指定します。
検索スコープ: 検索処理の対象として考慮する、ベースDNのエントリまたはその下のエントリのスコープを指定します。
処理中に別名を検出した場合に使用する間接参照ポリシー。
検索で返されるエントリの最大数を指定するサイズ制限です(–1の場合、検索結果は制限されません)。
時間制限: サーバーが検索処理に費やす時間の最大の長さを(エントリの最大数を指定しない場合はゼロ)を秒単位で指定します。
タイプのみフラグ: 返されたエントリに属性タイプのみを含めるか、タイプと値の両方を含めるかを示します。
検索フィルタ: 一致するエントリを特定するために使用する基準を指定します。
検索属性: 一致するエントリに含める属性を指定します。
検索リクエストとともに添付可能なコントロール: リクエスト・メッセージとともに添付されたクリティカル・メッセージがターゲット・ディレクトリ・サーバーでサポートされていない場合、エラーが返されます。
注意:
現在のバージョンでは、バイナリ型はサポートされず、属性値はutf8文字列として必ずエンコードされます。
アウトバウンド検索操作を使用するには、次の手順を実行します。
「リクエスト構成の検索」ページを使用して、検索スコープ、検索リフェラルおよび検索エイリアス遅延処理に関連する検索情報を指定します。
「検索」(レスポンス属性)ページを使用して、ターゲットのLDAPディレクトリ・サーバーで使用可能なオブジェクト・クラスを使用して検索操作レスポンスのパラメータを構成します。
2つ以上のオブジェクト・クラスを選択した場合、すべての属性の集合が表示され、共通の属性は2回表示されません。
図12-20に例を示します。
DSML操作では、LDAPリクエストおよびレスポンスをXMLドキュメント・フラグメントとして表示します。LDAPアダプタの「Dsml」画面を使用して、DSMLリクエストを実行するように指定し、オプションでLDAPの操作画面でそのDSMLリクエストの最大リクエスト・サイズを入力します。
DSML実行リクエストを使用するには、次の手順を実行します。
LDAPの「操作タイプ」画面で、「Dsml」を指定します。
「Dsml」画面が表示されます。図12-22を参照してください。
この画面で、オプションで「最大DSMLリクエスト・サイズ」を入力します。DSMLバッチ・リクエストに関与できる最大リクエスト数を制御する場合は、このプロパティを設定します。着信DSMLリクエストは、含まれているリクエストの合計数がこの数字未満の場合にのみ実行されます。
「次へ」をクリックします。DSML操作の「終了」画面に、LDAPのWSDLファイル、jcaファイルおよびxsdファイルが表示されます。
LDAPアダプタでは、ディレクトリ・サーバーからのイベントのパブリッシュをサポートしています。具体的には、一方向のインバウンド相互作用、非同期通知モデルを介したディレクトリ・サーバーからの非同期イベントのパブリッシュをサポートしています。
LDAPアダプタは、ディレクトリ情報ツリー内のエントリの追加、削除、変更などのイベントをリスニングして、このようなイベントをパブリッシュします。LDAPイベント・コンシューマ・シングルトンは、選択された計画に従ってディレクトリ・サーバーに接続して変更をリスニングし、このようなイベントを処理してLDAPアダプタ・クライアントにパブリッシュします。
デフォルトでは、LDAPアダプタはイベントをディレクトリ・サーバーから受信した順にパブリッシュします。
LDAPアダプタには、2つのタイプのインバウンド・アクティビティがあります。
エントリ変更通知を使用すると、ソース・ディレクトリ・サーバーで作成または変更されたエントリを取得できます。結果には、変更されたエントリおよび変更タイプに関する情報が含まれます。
このメカニズムはタイムスタンプ・ベースの検索に基づいているため、外部構成を必要とせず、ほとんどのディレクトリ・サーバーでサポートされています。時間ベースの検索では、ベース・タイムスタンプ以降のすべてのエントリに対して検索が実行されます。ベース・タイムスタンプは、後続のタイムスタンプ・ベースの検索のために更新されます。
検索では、LDAPアダプタが最後のタイムスタンプまでの結果を返し、その後、ベース・タイムスタンプを最後のタイムスタンプに更新します。構成した時間間隔は、すべてのイベントに対するタイムスタンプ・ベースの検索の繰返しが次に行われる日時を示します。
タイムスタンプ・ベースの検索では、追加または変更されたエントリの通知のみが行われます。エントリ変更通知では、削除されたエントリを検出することはできません。このメカニズムでは、変更されたエントリに関する通知のみが行われ、エントリが変更されたかどうかは示されますが、行われた変更の詳細は公開されません。
削除されたエントリを検出するためのプロビジョニングはないため、変更操作とDN変更操作を区別する方法はありません。
具体的には、エントリ変更通知では、DNの変更操作によってエントリが結果セットのスコープに入ったときやスコープから出たとき、または検索フィルタで使用されている属性値に対する変更操作が実行されたときの通知は行われません。
タイムスタンプは各サーバーのクロックを使用して生成されるため、特定のレプリカに非線形順序で表示される可能性があることから、タイムスタンプ・ベースの検索をディレクトリ・サーバーのマルチマスター設定で実行することはできません。
エントリ変更通知では、操作属性createTimestampおよびmodifyTimestampに基づいたタイムスタンプ・ベースの検索が使用されるため、タイムスタンプ・ベースの検索を正常に実行するためには、ディレクトリ・サーバーでこれらの属性を使用可能にし、索引付けして有効にする必要があります。
これらの属性のいずれかが索引付けされていなかったり、正常に機能していない場合、LDAPアダプタ・クライアントのログにUnavailable Critical Extensionという例外が書き込まれることがあります。
これらの属性がタイムスタンプ検索時に使用できるように適切に索引付けされていることを確認するには、ディレクトリ・サーバーのドキュメントを参照してください。
注意:
PageSize構成はOracle Internet Directoryサーバーへの接続時には機能しないため、Oracle Internet Directoryサーバーでは使用しないでください。構成した場合、pageSize制限を超えて発生したイベントの数は処理されません。
エントリ変更通知を構成するには、次の手順を実行します。
変更ログ通知イベントは、ディレクトリ・サーバーのエントリで実行された変更の詳細ログを提供します。
イベントには変更詳細が含まれ、この変更を発生させたソース・サーバーで実行されたリクエスト・メッセージを再構成します。このイベントは、同じリクエストをターゲット・サーバー上で再現する必要がある場合に特に有用です。変更ログ通知は、アクティビティの詳細を提供するという点で非常に強力な機能です。
変更ログ通知を使用して、ソースLDAPディレクトリを他のサブシステムと増分的に同期できます。このメカニズムはLDAP仕様の一部ではなく、この機能の使用前にはソース・ディレクトリ・サーバーで特定の構成が必要になることがあるため、使用前にディレクトリ・サーバーの実装およびOracle認証マトリクスをチェックする必要があります。
変更ログ通知は、専用ディレクトリ・サーバーまたは専用レプリケーション・サーバーのいずれかとして構成されているサーバー・インスタンスでは使用できません。
変更ログ通知を構成するには、次の一般的な手順を実行します。ここでは、一般的なフローにおける前の手順をすでに実行し、「操作タイプ」画面が表示されていることを前提としています。
次の表に、変更ログ通知のエラーを示します。
| エラー名 | 説明 | ステータス |
|---|---|---|
|
インバウンド・アダプタ・サービスからディレクトリ・サーバーへの接続が停止しています。これは |
適切なエラー・メッセージを伴うリモート・フォルト。アダプタはディレクトリ・サーバーへの接続を再試行する必要があります。 |
|
変更ログ・メカニズムはターゲット・ディレクトリ・サーバーでサポートされていません。これは |
致命的な例外であり、インバウンド・サービスは停止します。 |
|
変更番号が無効であるか、ディレクトリ・サーバーにより認識されません。ディレクトリ・サーバーの管理者に連絡してください。有効な変更番号を指定してください。変更番号が無効であるか、パージされて認識されなくなった可能性があります。手動で新しい変更番号をデータベース内に指定できます。 これは |
この場合、インバウンド・サービスにより初期変更番号が特定されず、処理を開始できないため、致命的な例外が発生します。 |
EndpointActivationError |
エンドポイントのアクティブ化中に、1つ以上のアクティブ化仕様エラーによって検証が失敗しました。 これはLdapValidationExceptionです。 |
バインディング・フォルト。 |
SizeLimitExceededException |
指定されたサイズ制限を超えました。 |
- |
TimeLimitExceededException |
指定された時間制限を超えました。 |
[-] |
注意:
実行時、LDAPサーバーで発生したエラー/ステータス・コードは、クライアントに送信されることも、サーバーで表示されることもありません。
次の表に、LDAPアダプタを使用したエントリ変更通知に関連して発生する可能性のあるエラーを示します。エラー名、エラー名の説明、エラーがレポートされた後の構成のステータス、および再試行可能性を示しています。
表12-3 エントリ変更通知のエラー条件
| エラー名 | 説明 | ステータス |
|---|---|---|
InboundConnectionDown |
インバウンド・アダプタ・サービスからDSへの接続が停止しています。これはLdapConnectionExceptionです。 |
適切なエラー・メッセージを伴うリモート・フォルト。LDAPアダプタはDSへの接続を再試行する必要があります。 |
MalformedDN |
イベント・スコープ内のbaseDNが不正です。これはLdapValidationExceptionです。 |
バインディング・フォルト。 |
MalformedFilter |
検索フィルタはLDAPフィルタの文字列表記に対して不正です。http://www.ietf.org/rfc/ rfc2254.txtを参照してください LdapValidationException |
バインディング・フォルト。 |
InvalidAdapterConfiguration |
アダプタ・インバウンド・サービス構成は、1つ以上の理由で無効です。 LdapValidationException |
違反を示す適切なメッセージを伴うバインディング・フォルト。 |
EndpointActivationError |
エンドポイントのアクティブ化中に、1つ以上のアクティブ化仕様エラーによって検証が失敗しました。 LdapValidationException |
バインディング・フォルト。 |
EventProcessingError |
ディレクトリ・サーバーから受信したイベントの処理中にエラーがあった場合に発生します。 LdapRetriableResourceException |
フォルトは構成済の再試行パラメータに従って再試行され、適切な再試行が実行された後は拒否されます。 |
LDAPアダプタでは、次のログが使用可能です。これらのランタイム・ロガーは、WebLogicコンソールで表示できます。それぞれのロギング・レベルは親から継承されます。
oracle.soa.adapter.ldap.inbound
oracle.soa.adapter.ldap.outbound
oracle.soa.adapter.ldap.connection
oracle.soa.adapter.ldap.transaction
LDAPアダプタは、有効なセキュリティ資格証明を使用してサインオンする必要があります。これを可能にするために、Oracle WebLogic Serverではコンテナ管理のサインオンとアプリケーション管理のサインオンの両方がサポートされています。
コンテナ管理のサインオンでは、ユーザーがOracle WebLogic Serverにサインオンし、エンタープライズ情報システムに個別にサインインしなくてもリソース・アダプタを介してアクセスできます。
Oracle WebLogic ServerとLDAPエンタープライズ情報システムでは独立したセキュリティ・レルムが保守されているため、これは資格証明マッピングを使用して実現されます。Oracle WebLogic Serverのセキュリティ・プリンシパルは、エンタープライズ情報システムへのアクセスに必要な対応する資格証明にマップされます。アダプタのデプロイメント・ディスクリプタで機密性の高い資格証明情報を格納する必要はありません。
LDAPアダプタは、簡易認証(簡易バインド)を使用して、LDAPサーバーを認証します。たとえば、ユーザー名およびパスワードをディレクトリ・サーバーにバインドします。
SASLまたはその他の認証メカニズムはサポートしません。
LDAPアダプタは、接続先のサーバーによって提供された有効期限、再試行などの追加のパスワード・ポリシーは考慮しません。
アウトバウンド資格証明マッピングを使用すると、WebLogic Serverのユーザー名を、リソース・アダプタを使用して接続するエンタープライズ情報システム(EIS)のユーザー名にマップできます。リソース・アダプタ内のすべてのアウトバウンド接続プールに対してデフォルトのアウトバウンド資格証明マッピングを使用することも、個々の接続プールに特定のアウトバウンド資格証明マッピングを指定することもできます。
次の方法を実行すると、ConnectionFactoryプロパティでbindDNおよびpasswordを指定しなくても、資格証明マッピングを作成できます。
資格証明マッピングを指定した場合、その資格証明マッピングはConnectionFactoryで構成したbindDNおよびpasswordプロパティよりも優先されます。このコネクション・ファクトリは、LDAPコネクション・ファクトリと同様の方法で使用してください。
最後の手順を完了すると、WebLogic Serverユーザーのマッピングに使用するエンタープライズ情報システムのユーザー名とパスワードの構成は完了です。
Secure Sockets Layer (SSL)は、クライアントとサーバー間の通信に対して暗号化されたセキュアな通信を提供します。SSLを介したLDAPの環境におけるSSLの概要は、図12-27を参照してください。
注意:
ユーザーのパスワードを変更できるのは、SSL使用時のみです。Active Directoryのエンドポイント設定を確認し、SSLを使用するように切り替えます。パスワードの複雑さが不足している場合、SSLでユーザーのパスワードを変更すると、エラーが発生することがあります。たとえば、パスワードが英数字以外の文字、大文字、小文字、数字の組合せになっていなかったり、短すぎたりする場合です。パスワードの複雑さに関するActive Directoryの設定を無効にするか、複雑なパスワードを使用してください。機密データがリモート・サーバーへ転送される環境(クレジット・カード情報のHTTPサーバーへの送信など)では、セキュリティの問題は非常に重要です。このような場合、セキュリティには主に次の2つの要件があります。
データ交換をしているリモート・サーバーの信頼性
データの傍受を試みる第三者からの保護
LDAPアダプタでSSL証明書および暗号化を使用すると、この2つのセキュリティ要件が満たされます。
SSL環境でクライアントの信頼を得るために、サーバーは認識済の認証局から証明書(X.509証明書など)を取得します。どのクライアントも、少数のパーティしか信頼しません。サーバーが信頼されているパーティの1つである場合、またはサーバーの証明書がそれらの信頼されているパーティのいずれかで発行されたものである場合は、間接的であるにしても信頼性があります。これは、サーバー認証とも呼ばれます。LDAPアダプタは、このタイプのサーバー認証SSLハンドシェイクを提供します。
LDAPアダプタでは、拒否されたメッセージという概念がないため、再試行不可能な例外を発生させる必要があります。
注意:
LDAPアダプタは、server authenticationまたはserver-side authenticationのみをサポートします。LDAPサーバー認証クライアントがクライアント証明書をそのトラスト・ストアで認証する二重認証はサポートしません。証明書およびトラスト・ストアの使用を示す図は、図12-28を参照してください。
アダプタ・サービスのバインディング・プロパティとして、composite.xml内にペイロード・サイズしきい値を設定できます。
デフォルトでは、ペイロード・サイズしきい値に制限はありません。ただし、LDAPアダプタでは、Fusion Middlewareにパブリッシュされるメッセージはいずれもペイロード・サイズしきい値制限を下回っている必要があるというルールを適用しています。違反しているメッセージは拒否されます。LDAPアダプタでは、拒否されたメッセージという概念がないため、このかわりに再試行不可能な例外を発生させます。再試行シナリオにおける結果は変わらないため、payloadSizeThresholdを再試行しても意味がありません。
LDAPアダプタは可用性が高く、メッセージの損失なしで変更を1回かぎり伝播します。LDAPアダプタは、アクティブなクラスタ内にシングルトンとしてデプロイされます。これは、常にLDAPアダプタのシングル・インスタンスのみがディレクトリ・サーバーからの通知を受信することを意味します。高可用性サポートは、インバウンド操作にのみ適用されます。LDAPアダプタでは、アウトバウンド操作に対するトランザクション・サポートを提供していません。
LDAPアダプタの例外には、次のタイプの例外があります。
インバウンド再試行可能例外
インバウンド再試行不可例外
アウトバウンド再試行可能例外
アウトバウンド再試行不可例外
インバウンド再試行可能例外は通常、接続に関連しています。LDAPアダプタは、接続または再試行可能例外条件が修正されるまで再試行します。
このような例外には、次のバインディング・プロパティが適用されます。再試行プロパティが指定されていない場合、再試行は無限に行われます。
表12-4 インバウンド再試行可能JCA LDAPアダプタ・プロパティ
| プロパティ名 | 使用可能 | 説明 |
|---|---|---|
Jca.retry.count |
[-] |
拒否までの最大再試行回数を示します。 |
Jca.retry.interval |
秒単位 |
再試行の時間間隔を示します。 |
Jca.retry.backoff |
正の整数 |
再試行間隔の増分ファクタを示します。 |
Jca.retry.maxInterval |
[-] |
再試行間隔の最大値を示します。 |
Jca.retry.maxPeriod |
[-] |
すべての再試行の累積時間合計の上限(強い制限)です。 |
LDAPアダプタは、構成済のバインディング・プロパティに従って再試行を実行します。これらのバインディング・プロパティが指定されていない場合、コンポジットの一部としてフォルト・ポリシーが組み込まれていれば、フォルト・ポリシーによって再試行が実行されます。
アウトバウンド再試行可能例外は、次のプロパティによって制御します。
表12-5 アウトバウンド再試行可能LDAPアダプタJCAプロパティ
| プロパティ名 | 使用可能 | 説明 |
|---|---|---|
|
[-] |
拒否するまでの最大再試行回数を示します。 |
|
秒単位 |
再試行の時間間隔を示します。 |
|
正の整数 |
再試行間隔の増分ファクタを示します。 |
|
[-] |
再試行間隔の最大値を示します。 |
Jca.retry.maxPeriod |
[-] |
すべての再試行の累積時間合計の上限(強い制限)です。 |
Jca.retry.count |
[-] |
拒否までの最大再試行回数を示します。 |
Jca.retry.interval |
秒単位 |
再試行の時間間隔を示します。 |
LDAPアダプタのサンプルについては、SOAサンプルのサイトを参照してください。
次の表に、LDAPアダプタで使用可能なサンプルを示します。
表12-6 LDAPアダプタのサンプル
| サンプル | 説明 |
|---|---|
Ldap_Search |
ディレクトリ・サーバーでエントリを検索し、特定のソート・キーで結果をソートします。 |
Ldap_Modify |
LDAPアダプタを使用してエントリを変更、削除または名前変更します。 |
Ldap_Incremental_Sync |
ソース・ディレクトリ・サーバー上のイベントを取得し、これらのイベントをターゲット・ディレクトリ・サーバーにレプリケートします。 |
Ldap_DSML_Service |
LDAPアダプタを使用するDSMLゲートウェイ・サービス。 |
