1. Oracle Internet Directoryの管理
  2. ディレクトリ・サービスの理解
  3. Oracle Internet Directoryの概念およびアーキテクチャの理解

3 Oracle Internet Directoryの概念およびアーキテクチャの理解

Oracle Internet Directoryのアーキテクチャの説明と、Oracle Internet Directoryの基本要素(ディレクトリ・エンティティ、属性、オブジェクト・クラス、ネーミング・コンテキスト、セキュリティ管理など)の概念的な説明について理解します。

この項では、次の項目について説明します。

3.1 Oracle Internet Directoryのアーキテクチャの理解

Oracle Internet Directory内の様々なコンポーネントのコンテキストの説明について理解します。

この項では、次の項目について説明します。

3.1.1 Oracle Internet Directoryのノード

Oracle Internet Directoryのノードは、同じディレクトリ・ストアに接続された1つ以上のディレクトリ・サーバー・インスタンスで構成されます。ディレクトリ・ストア(ディレクトリ・データのリポジトリ)は、Oracle Databaseです。

ノート:

同じドメイン内のすべてのOracle Internet Directoryインスタンスは、同じOracle Databaseに接続します。

図3-1は、単一ノードで実行される様々なディレクトリ・サーバーの要素とその関係を示しています。

Oracle Net Servicesは、Oracle Databaseサーバーと次に示すものとの間のすべての接続に使用されます。

  • Oracleディレクトリ・サーバー非SSLポート(デフォルトでは3060)

  • Oracleディレクトリ・サーバーSSL対応ポート(デフォルトでは3131)

  • OIDモニター

LDAPは、ディレクトリ・サーバーと次のものとの間の接続に使用されます。

  • Oracle Directory Service Manager

  • Oracleディレクトリ・レプリケーション・サーバー

Oracleディレクトリ・サーバー・インスタンスとOracleディレクトリ・レプリケーション・サーバーは、オペレーティング・システム経由でOIDモニターに接続します。

ノート:

Oracle Internet Directory 11 gリリース1(11.1.1.7.0)以降、Oracle Databaseにキープ・アライブ・メッセージを送信するためにOracle Internet DirectoryサーバーでOCIPing()をコールするように指定できます。こうしたメッセージの頻度は、新しいorclMaxTcpIdleConnTime属性によって決定されます。

この属性に、Oracle Internet DirectoryサーバーとOracle Database間のファイアウォールのタイムアウト値よりも小さい値を設定することによって、データベース接続の切断が避けられます。

詳細は、「DSA構成エントリの属性」を参照してください。

図3-1 一般的なOracle Internet Directoryのノード

一般的なOracle Internet Directoryのノード

図3-1に示すように、Oracle Internet Directoryのノードには次の主要な要素が組み込まれています。

表3-1 Oracle Internet Directoryのノード

要素 説明

Oracleディレクトリ・サーバー・インスタンス

LDAPサーバー・インスタンスまたはディレクトリ・サーバー・インスタンスとも呼ばれ、特定のTCP/IPポートでリスニングする単一のOracle Internet Directoryディスパッチャ・プロセスを介して、ディレクトリ・リクエストに応答します。1つのノードに、異なるポートでリスニングする複数のディレクトリ・サーバー・インスタンスを設定できます。

Oracleディレクトリ・レプリケーション・サーバー

レプリケーション・サーバーとも呼ばれ、他のOracle Internet Directoryシステム内のレプリケーション・サーバーの変更を追跡し、その内容を送信します。1つのノードのレプリケーション・サーバーは、1つに限られます。レプリケーション・サーバーを構成するかどうかは選択できます。

Oracle Databaseサーバー

ディレクトリ・データを格納します。データベースは、ディレクトリ・サーバー・インスタンスと同じノードに置くことができます。

ノート: 顧客データのサイズが増大するにつれてOracle Internet Directoryで大量のデータ容量が必要になる可能性に備え、またデータベース問合せの最適なパフォーマンスを常に実現するために、データベースをこのディレクトリ専用に使用することを強くお薦めします。

OIDモニター(OIDMON)

LDAPサーバー・プロセスおよびレプリケーション・サーバー・プロセスを開始、モニターおよび終了します。oidctlなどのプロセス管理コマンドを呼び出す場合やFusion Middleware Controlを使用してサーバー・インスタンスを起動または停止する場合は、このプロセスによってコマンドが解釈されます。

また、OIDMONはサーバーをモニターし、異常な理由で実行が停止した場合に再起動させます。

OIDMONは、OIDLDAPDのデフォルト・インスタンスを起動します。OIDCTLコマンドを使用してOIDLDAPDのデフォルト・インスタンスが停止された場合、OIDMONがそのインスタンスを停止します。ただし、wlst start()によってOIDMONが開始されると、OIDMONはデフォルトのインスタンスを再起動します。

OIDモニターのすべてのアクティビティは、$DOMAIN_HOME/servers/OID/logs/componentName/oidmon-xxxx.logファイルに記録されます。このファイルは、Oracle Internet Directoryサーバー・ファイル・システム上にあります。

OIDモニターは、オペレーティング・システムのメカニズムを介して、サーバーの状態をチェックします。

OID制御ユーティリティ(OIDCTL)

Oracle Internet Directoryサーバーの表にメッセージ・データを配置して、OIDモニターと通信します。このメッセージ・データには、各Oracleディレクトリ・サーバー・インスタンスの実行に必要な構成パラメータが含まれます。通常は、レプリケーション・サーバーを起動および停止するためにのみ、コマンド行から使用されます。OIDCTLは、Oracle Internet Directoryのステータスの確認にも使用されます。

Oracleディレクトリ・レプリケーション・サーバーはLDAPを使用して、Oracleディレクトリ(LDAP)サーバー・インスタンスと通信します。データベースとの通信には、すべてのコンポーネントでOCI/Oracle Net Servicesを使用します。Oracle Directory Services Managerとコマンド行ツールは、LDAPを介してOracleディレクトリ・サーバーと通信します。

3.1.2 Oracleディレクトリ・サーバー・インスタンス

このトピックで示す図および説明から、Oracleディレクトリ・サーバー・インスタンスのアーキテクチャについて理解できます。

図3-2に、LDAPサーバー・インスタンスとも呼ばれるOracleディレクトリ・サーバー・インスタンスを示します。

図3-2 Oracleディレクトリ・サーバー・インスタンスのアーキテクチャ

図3-2の説明が続きます
「図3-2 Oracleディレクトリ・サーバー・インスタンスのアーキテクチャ」の説明

1つのインスタンスは、1つのディスパッチャ・プロセスと1つ以上のサーバー・プロセスで構成されます。Oracle Internet Directoryのディスパッチャ・プロセスとサーバー・プロセスでは、複数のスレッドを使用して負荷が分散されます。LDAPクライアントは、ポートでLDAPコマンドをリスニングしているOracle Internet Directoryリスナー/ディスパッチャ・プロセスにLDAPリクエストを送信します。

Oracle Internet Directoryリスナー/ディスパッチャは、起動時に構成されている数のサーバー・プロセスを起動します。サーバー・プロセスの数は、インスタンス固有の構成エントリのorclserverprocs属性によって制御されます。orclserverprocsのデフォルト値は1です。複数のサーバー・プロセスを使用することで、Oracle Internet Directoryでマルチ・プロセッサ・システムの利点を活かすことができます。

Oracle Internet Directoryディスパッチャ・プロセスは、Oracle Internet Directoryサーバー・プロセスへのLDAP接続をラウンドロビン方式で送信します。各サーバーに受け入れられるLDAP接続の最大数は、デフォルトでは1024です。この数は、次の形式の識別名を持つインスタンス固有の構成エントリの属性orclmaxldapconnsを変更することで増やすことができます。 

cn=componentname,cn=osdldapd,cn=subconfigsubentry

3.1.3 Oracle Internet Directoryのポート

Oracle Internet Directoryコンポーネントは、Oracle Identity Management 11gインストーラによっても、コマンド行ツールでも作成できます。Oracle Internet Directoryを作成するプログラムは特定のステップに従ってSSLおよび非SSLポートを割り当てます。

まず、非SSLポートとして3060の使用を試みます。そのポートが使用できない場合、3061から3070の範囲のポートを試し、次に13060から13070の範囲のポートを試します。

同様に、Oracle Internet Directoryを作成するプログラムは、SSLポートとして3131を試し、次に3132から3141の範囲のポート、その後13131から13141の範囲のポートを試します。

3.1.4 ディレクトリ・メタデータ

ディレクトリ・メタデータは、ディレクトリ・サーバーが実行中にLDAPリクエストを処理するために使用する情報です。基礎となるデータ・リポジトリに格納されます。起動中に、ディレクトリ・サーバーはこの情報を読み取って、ローカル・メタデータ・キャッシュに格納します。実行中にこのキャッシュを使用して、着信LDAP操作リクエストを処理します。

ノート:

メタデータ・キャッシュはライトスルー・キャッシュです。LDAP操作では、最初にデータベースに書き込み、次に対応するキャッシュ・エントリを無効化します。このエントリをその後検索すると、キャッシュがリフレッシュされます。

ディレクトリ・サーバーのローカル・メタデータ・キャッシュには、次の種類のメタデータが格納されます。

  • ディレクトリ・スキーマ

    ディレクトリ・サーバーによりサポートされるオブジェクト・クラス、属性、一致規則の定義。ディレクトリ・サーバーは、ディレクトリ・オブジェクトの作成および変更時にこの情報を使用します。ディレクトリ・オブジェクトとは、オブジェクト・クラスおよびそれに関連付けられた属性と一致規則の集合です。「ディレクトリ・スキーマの管理」を参照してください。

  • アクセス制御ポリシー・ポイント(ACP)

    ドメインにある情報へのアクセスを定義し、制御するためのディレクトリ管理ドメイン。ディレクトリ・サーバーは、特定のLDAP操作をユーザーが実行できるかどうかを判断するときにACPを使用します。「ディレクトリ・アクセス制御の管理」を参照してください。

  • ルートDSEエントリ

    ルートDSE(ディレクトリ・サービス・エージェント固有のエントリ)には、ディレクトリ・サーバー自体に関する情報を格納する複数の属性が入っています。これらの属性には次のような情報項目が含まれます。

    • ネーミング・コンテキスト識別名

    • サブ・スキーマ・サブエントリ識別名

    • 上位参照(参照)識別名

    • Oracle Internet Directory構成コンテナやレジストリ・コンテナのような特殊なエントリ識別名

    • 変更ログ・コンテナや変更ステータス・コンテナのような特殊なエントリ識別名

    • レプリケーション承諾コンテナの識別名

    「DSEの属性」を参照してください。

  • 権限グループ

    アクセス制御ポリシーで使用できるグループ。

    ディレクトリ・スキーマは、標準のgroupofuniquenamesオブジェクト・クラスとgroupofnamesオブジェクト・クラスによってディレクトリ・グループ・オブジェクトをサポートします。これらのオブジェクト・クラスは、配布リストやメーリング・リストのようなグループに関する情報を格納します。

    Oracle Internet Directoryは、orclprivilegegroupと呼ばれる補助オブジェクト・クラスによって、これらの標準グループ・オブジェクトを拡張します。このオブジェクト・クラスは、アクセス制御ポリシーで使用できる権限グループをサポートし、ユーザーのグループに対するアクセスの許可や拒否を柔軟に行えるようにします。ディレクトリ・サーバーはこの情報を次の場合に使用します。

    • 特定のユーザーに関してサブスクライブされた権限グループを検索するためのLDAPバインド操作

    • 権限が付与されたグループに対するアクセスを許可または拒否するディレクティブがポリシーにあるかどうかのアクセス制御ポリシーの評価

    関連項目:

    Oracle Internet Directoryでの動的グループと静的グループの管理

  • カタログ・エントリ

    基礎となるデータベースで索引付けされた属性に関する情報を入れる特別なエントリ。ディレクトリは、ディレクトリ検索操作中にこの情報を使用します。「属性を検索するためのOracle Internet Directoryでの索引オプション」を参照してください。

  • 共通エントリ

    ホスティングされた企業に関する情報を入れる特別なエントリ。ホスティングされた企業とは、別の企業からサービスを提供される企業です。このエントリのメタデータには、ホスティングされた企業の識別名、ユーザー検索ベース、ニックネームなどの属性が入っています。詳細は、「レルムの計画、デプロイおよび管理」を参照してください。

  • プラグイン・エントリ

    プラグイン・イベントをトリガーする操作の種類と、操作のどの時点でそのプラグインをトリガーするかに関する情報を入れる特別なエントリ。この詳細は、「Oracle Internet Directoryサーバー・プラグインの開発」を参照してください。

  • パスワード検証エントリ

    暗号タイプとベリファイア属性タイプに関する情報を入れる特別なエントリ。この詳細は、「パスワード・ベリファイアの管理」を参照してください。

  • パスワード・ポリシー・エントリ

    ユーザー・パスワード資格証明についてディレクトリ・サーバーにより施行されるポリシーに関する情報の入った、1つ以上の特別なエントリ。ディレクトリ・サーバーは、パスワード・ポリシーを施行するために実行時にこの情報を使用します。「パスワード・ポリシーの管理」を参照してください。

3.2 Oracle Internet Directoryによる検索リクエストの処理方法の理解

Oracle Internet Directoryによる標準LDAP検索操作と永続LDAP検索操作の処理方法について理解します。

次のトピックでは、Oracle Internet Directoryでの様々なLDAP検索操作のコンテキストについて説明します。

3.2.1 標準LDAP検索操作

標準LDAP検索リクエストを処理する手順に従ってください。

この例では、Oracle Internet Directoryがどのように検索リクエストを処理するかを示します。

  1. ユーザーまたはクライアントが検索リクエストを入力します。検索条件は、次の1つ以上のオプションによって決まります。

    • SSL: クライアントとサーバーは、SSLの暗号化と認証またはSSLの暗号化のみを使用するセッションを確立できます。SSLが使用されていない場合、クライアントのメッセージは平文で送信されます。

    • ユーザーのタイプ: ユーザーは、要求する機能の実行に必要な権限を持っているかどうかによって、特定のユーザーまたは匿名ユーザーのいずれかでディレクトリへのアクセスを要求できます。

    • フィルタ: ユーザーは、1つ以上の検索フィルタを使用して検索条件を絞り込むことができ、検索フィルタには、ブール条件and、or、notの他に、greater than、equal to、less thanなどの演算子を使用するものがあります。

  2. C APIは、LDAPプロトコルを使用して、ディレクトリへの接続リクエストをディレクトリ・サーバー・インスタンスに送信します。

  3. ディレクトリ・サーバーはユーザーを認証し、このプロセスはバインドと呼ばれます。ディレクトリ・サーバーは、アクセス制御リスト(ACL)もチェックして、そのユーザーが、リクエストした検索の実行を許可されているかどうかを検証します。

  4. ディレクトリ・サーバーは、LDAPからの検索リクエストをOracle Call Interface (OCI)およびOracle Net Servicesに変換し、Oracle Databaseに送信します。

  5. Oracle Databaseは、情報を取得し、その情報をディレクトリ・サーバー、C API、クライアントの順に返します。

ノート:

検索フィルタに指定できる属性の最大数は255です。

3.2.2 永続LDAP検索操作

永続検索は、初期検索の結果がOracle Internet DirectoryサーバーからLDAPクライアントに返された後も継続します。初期検索の終了後も、サーバーに対する接続は、クライアントが操作をバインド解除するか中止するまで維持されます。永続検索操作によって、クライアントは、検索範囲のエントリが変更された場合に通知を受信できます。エントリが変更されると、サーバーは、そのエントリの新しいコピーをLDAPクライアントに送信し、リクエストがあれば、その変更を記述したエントリ変更通知制御を含めます。

リリース11gリリース1 (11.1.1.9.0)以降では、Oracle Internet Directoryで永続検索操作がサポートされます。

永続検索操作では、次の制御を使用します。

  • 永続検索制御 - LDAPクライアントは、Oracle Internet Directoryサーバーに対して、検索結果を返すための特定のオプションを含む永続検索リクエストとともにこの制御を送信します。

  • エントリ変更通知制御 - クライアントからリクエストされると、サーバーは、検索リクエストの検索基準に一致する変更されたエントリごとに、クライアントにこの制御を返します。

永続検索は、構成エントリ、参照、エントリ別名などの特殊なエントリではサポートされません。

永続検索では、LDAPクライアントからサーバーへの接続を維持する必要があります。そのため、永続検索が大量に実行されると、LDAPの接続制限に達して新しい接続を確立できなくなる可能性があります。この状況の発生を避けるには、インスタンス固有の属性であるorclmaxpsearchconnsによって、LDAP永続検索操作に対して許可する最大接続数を指定します。

Oracle Internet DirectoryのLDAP永続検索操作の手順は、次のとおりです。

  1. LDAPクライアントは、Oracle Internet Directoryサーバーに対して認証を行います。

  2. クライアントは、アタッチされた永続検索制御とともに永続検索リクエストを発行します。この制御には、次の情報が指定されます。

    • changesOnly - このフィールドがFALSEの場合、サーバーは、検索基準に一致する結果の初期セットを返します。または、このフィールドがTRUEの場合、サーバーはそれらのエントリを返しません。

    • changeTypes - このフィールドは、クライアントが追跡する変更のタイプを指定します。検索基準に一致するエントリに対して後続の変更が行われると、サーバーは、それらの変更されたエントリをクライアントに返します。

      changeTypesフィールドは、次の1つ以上の値の論理ORです。

      • add: 1

      • delete: 2

      • modify: 4

      • moddn: 8

    • returnECs - このフィールドがTRUEの場合、サーバーは、変更された各エントリとともにエントリ変更通知制御も返します。

  3. OIDサーバーは、前のステップで説明したオプションを使用して永続検索リクエストを処理します。

    接続は、クライアントが操作をバインド解除するか中止するまで維持する必要があるため、サーバーはクライアントにSearchResultDoneメッセージを返しません。

  4. サーバーが検索結果を返すと、クライアントは、必要に応じてそれらの結果を処理します。

  5. LDAPクライアントは、バインド解除または中止のリクエストを送信して、永続検索操作を終了します。

関連項目:

3.3 Oracle Internet Directoryにあるディレクトリ・エントリの理解

オンライン・ディレクトリでは、オブジェクトに関する情報の集合はエントリと呼ばれます。エントリには、社員、会議室、E-Commerceパートナ、プリンタなどの共有ネットワーク・リソースに関する情報などが含まれます。

この項では、次の項目について説明します。

3.3.1 識別名とディレクトリ情報ツリー

オンライン・ディレクトリ内の各エントリは、識別名(DN)で一意に識別されます。識別名は、ディレクトリ階層におけるそのエントリの位置を正確に伝えます。この階層は、ディレクトリ情報ツリー(DIT)で示されます。

識別名とディレクトリ情報ツリーとの関係を理解するには、図3-3を参照してください。

図3-3 ディレクトリ情報ツリー

図3-3の説明が続きます
「図3-3 ディレクトリ情報ツリー」の説明

図3-3のDITには、Acme Corporationに所属する、Anne Smithという同じ名前を持つ2人の従業員のエントリが含まれています。この図のディレクトリ情報ツリーは、地理的および組織的な線で構造化されています。左のブランチに含まれているAnne Smithは、米国の販売部門に勤務しています。もう一方のAnne Smithは、英国のサーバー開発部門に勤務しています。

右のブランチのAnne Smithは、Anne Smithという一般名(cn)を持っています。彼女は、組織(o)がAcme、国(c)が英国(uk)で、Server Developmentという組織単位(ou)に勤務しています。

このAnne Smithエントリの識別名(DN)は次のとおりです。 

cn=Anne Smith,ou=Server Development,c=uk,o=acme

通常、識別名の形式は、最下位のDITコンポーネントを左側に配置し、下位のコンポーネントからルートに向かって順番に配置します。

識別名内の最下位コンポーネントは、相対識別名(RDN)と呼ばれます。たとえば、前述のAnne Smithのエントリの相対識別名はcn=Anne Smithです。同様に、Anne Smithの相対識別名のすぐ上のエントリに対応する相対識別名はou=Server Development、ou=Server Developmentのすぐ上のエントリに対応する相対識別名はc=ukです。したがって、DNはDITでの親子関係を反映したRDNの連結です。DN内では、RDNはカンマで区切ります。

DIT全体の中で特定エントリを検索するために、クライアントは、そのエントリの相対識別名のみではなく、完全な識別名を使用することによって、エントリを一意に識別します。たとえば、図3-3のグローバル組織内で、この2人のAnne Smithを混同しないように、それぞれの完全な識別名を使用します。同一組織単位内に同名の従業員が2人いる可能性がある場合は、一意の識別番号で各従業員を識別するなど、補助的な方法を使用してください。

3.3.2 エントリ・キャッシング

エントリに対して迅速で効率的な操作を行うために、Oracle Internet Directoryはエントリ・キャッシングを使用します。この機能を有効にした場合、Oracle Internet Directoryは、各エントリに一意の識別子を割り当て、指定された数の識別子をキャッシュ・メモリーに格納します。ユーザーがエントリに対する操作を行うと、ディレクトリ・サーバーは、キャッシュ内でエントリ識別子を検索し、対応するエントリをディレクトリから取得します。

ノート:

  • リリース11gリリース1 (11.1.1.6.0)から、エントリ・キャッシュが共有メモリーに配置されるようになったため、同じホスト上の複数のOracle Internet Directoryサーバー・インスタンスで同じキャッシュを共有できます。キャッシュを構成するための属性は、DSA構成エントリ内に置かれるようになりました。

  • エントリ・キャッシュはライトスルー・キャッシュです。LDAP操作では、最初にデータベースに書き込み、次に対応するキャッシュ・エントリを無効化します。このエントリをその後検索すると、キャッシュがリフレッシュされます。

関連項目:

3.4 Oracle Internet Directory内の属性の概念の理解

オンライン・ディレクトリ内の属性とその構文、ルールおよびオプションの概念的な説明について理解します。

この項では、次の項目について説明します。

3.4.1 オンライン・ディレクトリの属性

一般的な電話帳の場合、個人に関するエントリには住所や電話番号などの情報項目が含まれます。オンライン・ディレクトリでは、このような情報項目は属性と呼ばれます。一般的な従業員エントリの属性には、役職名、電子メール・アドレス、電話番号などがあります。

たとえば、図3-4では、英国(uk)のAnne Smithのエントリには、複数の属性が含まれており、それぞれAnne Smith固有の情報を提供します。これらはツリーの右側の円の中にリストされ、emailaddrs、printername、jpegPhotoおよびapp preferencesなどが含まれます。さらに、図3-4の各円も、それぞれの属性は表示されませんが、複数の属性が含まれたエントリです。

図3-4 Anne Smithのエントリの属性

図3-4の説明が続きます
「図3-4 Anne Smithのエントリの属性」の説明

各属性は、属性タイプと1つ以上の属性値で構成されます。属性タイプとは、その属性に含まれている情報の種類(jobTitleなど)です。属性値は、そのエントリで表される情報の具体的な内容です。たとえば、jobTitle属性に対する値にはmanagerがあります。

3.4.2 アプリケーションとシステムの構成属性

アプリケーションとシステムの構成属性について理解します。

属性には2種類の情報があります。

  • アプリケーション属性

    この情報は、ディレクトリ・クライアントによってメンテナンスおよび取得が行われ、ディレクトリの操作には影響しません。例として電話番号があります。

  • システム構成属性

    この情報は、ディレクトリ自体の操作に関係します。一部の操作情報(エントリの作成または変更のタイム・スタンプや、エントリを作成または変更するユーザーの名前など)は、サーバーを制御するディレクトリによって指定されます。アクセス情報などその他の操作情報は、管理者によって定義され、ディレクトリ・プログラムによって処理時に使用されます。

    関連項目:

    システム構成属性の詳細は、「システム構成属性の管理」を参照してください。

3.4.3 新規エントリごとに作成される属性

エントリをディレクトリに追加すると、エントリの検索能力を強化するために、Oracle Internet Directoryが自動的にいくつかのシステム構成属性を作成します。

これには次のものがあります。

表3-2 新規エントリごとに作成される属性

属性 説明

creatorsName

エントリ作成者の名前

createTimestamp

UTC(協定世界時)でのエントリの作成時間

modifiersName

エントリ変更者の名前

modifyTimestamp

UTCでの最後のエントリ変更時間

ユーザーがエントリを変更すると、Oracle Internet Directoryでは自動的にmodifiersName属性がエントリを変更したユーザーの名前に、modifyTimestamp属性がUTCで表したエントリ変更時間にそれぞれ更新されます。

関連項目:

システム構成属性の構成方法は、「システム構成属性の管理」を参照してください。

3.4.4 単一値と複数値の属性

属性は、単一値または複数値のいずれかです。単一値の属性には1つの値のみ設定でき、複数値の属性には複数の値を設定できます。複数値の属性の例には、グループ全員の名前を載せたグループ・メンバーシップ・リストがあります。

3.4.5 一般的なLDAP属性

Oracle Internet Directoryは、標準的なLDAP属性をすべて実装しています。より一般的なものについては、一部がInternet Engineering Task Force (IETF)のRFC 2798に定義されています。

表3-3を参照してください。

表3-3 一般的なLDAP属性

属性タイプ 属性の文字列 説明

commonName

cn

エントリの一般的な名前(Anne Smithなど)。

domainComponent

dc

ドメイン・ネーム・システム(DNS)にあるコンポーネントの識別名(dc=uk,dc=acme,dc=comなど)。

jpegPhoto

jpegPhoto

JPEGフォーマットの写真イメージ。バイナリ形式で格納されます。

organization

o

組織の名前(my_companyなど)。

organizationalUnitName

ou

組織内の単位の名前(Server Developmentなど)。

owner

owner

エントリの所有者を識別する名前(cn=Anne Smith, ou=Server Development, o= Acme, c=ukなど)。

surname、sn

sn

ユーザーの姓(Smithなど)。

telephoneNumber

telephoneNumber

電話番号((650) 123-4567、6501234567など)。

関連項目:

Oracle Internet Directoryが提供する複数の属性のリストは、『Oracle Identity Managementリファレンス』のOracle Identity ManagementのLDAP属性リファレンスに関する項を参照してください。

3.4.6 属性の構文

属性の構文とは、各属性にロード可能なデータの形式です。たとえば、telephoneNumber属性の構文の場合、電話番号は空白やハイフンを含む一続きの数値である必要があります。しかし、別の属性の構文では、そのデータを日付書式で表すか、または数値のみで表すかの指定が必要な場合もあります。各属性の構文は必ず1つのみです。

Oracle Internet Directoryは、Internet Engineering Task Force (IETF)のRFC 2252で指定されているほとんどの構文を認識するため、そのドキュメントに記述されている構文の大部分を属性に関連付けることができます。Oracle Internet Directoryは、RFC 2252構文の認識に加え、一部のLDAP構文も適用します。Oracle Internet Directoryですでにサポートされているこれらの構文以外に、新規の構文を追加することはできません。

関連項目:

『Oracle Identity Managementリファレンス』のLDAP属性の構文についてに関する項。

3.4.7 属性の一致規則

ディレクトリ・サーバーは、クライアントのリクエストに応じて、検索と比較の操作を実行します。この操作時に、ディレクトリ・サーバーは関連する一致規則を調査し、検索対象の属性値と、格納されている属性値との間の等価性を判断します。

たとえば、telephoneNumber属性に関連付けられた一致規則では、(650) 123-4567を(650) 123-4567または6501234567のいずれか、あるいはその両方と一致させることができます。属性の作成時に、属性を一致規則と関連付けます。

Oracle Internet Directoryは、標準的なLDAP一致規則をすべて実装しています。Oracle Internet Directoryですでにサポートされているこれらの一致規則以外に、新規の一致規則を追加することはできません。

関連項目:

3.4.8 属性オプション

属性タイプには様々なオプションがあり、検索または比較操作でその属性の値をどのように使用できるかを指定できます。

たとえば、ある従業員がロンドンとニューヨークという2つの住所を持っているとします。その従業員のaddress属性のオプションを使用すると、両方の住所を格納できます。

さらに、属性オプションは言語コードを含むことができます。たとえば、John DoeのgivenName属性のオプションを使用すると、彼の名前をフランス語と日本語の両方で格納できます。

オプション付きの属性とその基本属性は、明確に区別できます。オプションがない場合、両者は同じ属性です。たとえば、givenName;lang-fr=Jeanでは、基本属性はgivenNameであり、この基本属性のフランス語の値はgivenName;lang-fr=Jeanです。

1つ以上のオプションを持つ属性は、そのベース属性のプロパティ(一致規則、構文など)を継承します。前述の例を踏まえると、オプション付きの属性cn;lang-fr=Jeanは、cnのプロパティを継承します。

ノート:

属性オプションは識別名内では使用できません。たとえば、識別名cn;lang-fr=Jean, ou=sales,o=acme,c=ukは不適切です。

関連項目:

Oracle Internet Directoryでのディレクトリ・エントリの管理。

3.5 Oracle Internet Directory内のオブジェクト・クラスの理解

オブジェクト・クラスは、エントリの構造を定義する属性のグループです。ディレクトリ・エントリを定義するときは、1つ以上のオブジェクト・クラスを割り当てます。これらのオブジェクト・クラスの属性には、必須で値を指定する必要があるものもあれば、オプションで値を指定しなくてよいものもあります。

たとえば、organizationalPersonオブジェクト・クラスには、必須属性のcommonName (cn)とsurname (sn)が含まれており、オプション属性としてtelephoneNumber、uid、streetAddressおよびuserPassword.が含まれています。organizationalPersonオブジェクト・クラスを使用してエントリを定義するときは、commonName (cn)およびsurname (sn)に値を指定する必要があります。telephoneNumber、uid、streetAddressおよびuserPasswordに値を指定する必要はありません。

この項では、次の項目について説明します。

3.5.1 サブクラス、スーパークラスおよび継承

サブクラスは、別のオブジェクト・クラスから導出されたオブジェクト・クラスです。サブクラスが導出されるオブジェクト・クラスは、そのスーパークラスと呼ばれます。

たとえば、オブジェクト・クラスorganizationalPersonは、オブジェクト・クラスpersonのサブクラスです。逆に、オブジェクト・クラスpersonは、オブジェクト・クラスorganizationalPersonのスーパークラスです。

サブクラスは、そのスーパークラスの属性をすべて継承します。たとえば、サブクラスorganizationalPersonは、そのスーパークラスpersonの属性を継承しています。エントリも、そのスーパークラスが継承した属性を継承します。

ノート:

オブジェクト・クラス自体に値は含まれていません。値を持つのは、オブジェクト・クラスのインスタンス、つまりエントリのみです。サブクラスがスーパークラスから属性を継承するときは、スーパークラスの属性定義のみを継承します。

topと呼ばれる、スーパークラスを持たない特別なオブジェクト・クラスが1つあります。これは、ディレクトリ内のすべてのオブジェクト・クラスのスーパークラスの1つであり、その属性定義はすべてのエントリに継承されます。

3.5.2 オブジェクト・クラスのタイプの理解

使用可能なオブジェクト・クラスの様々なタイプについて理解します。

この項では、次の項目について説明します。

3.5.2.1 構造型オブジェクト・クラス

構造型オブジェクト・クラスは、オブジェクトの基本的側面を記述します。使用するオブジェクト・クラスの大部分は構造型オブジェクト・クラスであり、すべてのエントリは少なくとも1つの構造型オブジェクト・クラスに属している必要があります。構造型オブジェクト・クラスの例としては、personやgroupOfNamesがあります。

これらのオブジェクト・クラスは、実社会のエンティティと、その物理的属性および論理的属性をモデルとしています。たとえば、人、プリンタ、データベース接続などがあります。

構造型オブジェクト・クラスは、構造規則を使用して、特定のオブジェクト・クラスの下に作成可能なオブジェクトの種類に制限を与えます。たとえば、構造規則では、organization(o)オブジェクト・クラスの下にあるすべてのオブジェクトはorganizational unit(ou)であることが要求されます。この規則に従うと、personオブジェクトをorganizationオブジェクト・クラスのすぐ下に入力することはできません。同様に、構造規則では、personオブジェクトの下にorganizational unit(ou)オブジェクトを置くことはできません。

3.5.2.2 補助型オブジェクト・クラス

補助型オブジェクト・クラスは、オプションの属性をグループ化したもので、エントリ内の既存の属性リストを拡張します。構造型オブジェクト・クラスと異なり、エントリを格納する場所に関する制限はなく、DITでのエントリの位置に関係なく、任意のエントリに置くことができます。

ノート:

Oracle Internet Directoryは、構造規則を強制しません。したがって、構造型オブジェクト・クラスと補助型オブジェクト・クラスは同様に処理されます。

3.5.2.3 抽象型オブジェクト・クラス

抽象型オブジェクト・クラスは、仮想のオブジェクト・クラスです。これは、便宜上、オブジェクト・クラス階層の最上位レベルを指定する際にのみ使用されます。エントリに対する唯一のオブジェクト・クラスにすることはできません。たとえば、オブジェクト・クラスtopは抽象型オブジェクト・クラスです。これは、すべての構造型オブジェクト・クラスに対するスーパークラスとして必要ですが、単独では使用できません。

topオブジェクト・クラスには、必須属性であるobjectClassの他に、次のオプション属性があります。top内のオプション属性は次のとおりです。

  • orclGuid: エントリが移動しても変わらないグローバル識別子

  • creatorsName: オブジェクト・クラス作成者の名前

  • createTimestamp: オブジェクト・クラスが作成された時間

  • modifiersName: オブジェクト・クラスを最後に変更したユーザーの名前

  • modifyTimestamp: オブジェクト・クラスが最後に変更された時間

  • orclACI: この属性が定義されているアクセス制御ポリシー・ポイント(ACP)の下のサブツリーにあるすべてのエントリに適用されるアクセス制御リスト(ACL)ディレクティブ

  • orclEntryLevelACI: 特殊なユーザーなどの特定のエンティティのみに関連するアクセス制御ポリシー

    関連項目:

3.6 ディレクトリ・ネーミング・コンテキスト

ディレクトリ・ネーミング・コンテキストは、全体が1つのサーバーに存在するサブツリーです。完全なサブツリーである必要があります。つまり、サブツリーの頂点となるエントリから始まり、下位方向にリーフ・エントリまたは従属ネーミング・コンテキストへの参照のいずれかまでを範囲とする必要があります。単一エントリからディレクトリ情報ツリー(DIT)全体までをサイズの範囲とすることができます。

図3-5に、適切なネーミング・コンテキストと不適切なネーミング・コンテキストを示します。左側の適切なコンテキストは連続しており、右側の不適切なコンテキストは連続していないことに注意してください。

図3-5 適切なネーミング・コンテキストと不適切なネーミング・コンテキスト

図3-5の説明が続きます
「図3-5 適切なネーミング・コンテキストと不適切なネーミング・コンテキスト」の説明

ユーザーが特定のネーミング・コンテキストを検出できるようにするには、ldapmodifyを使用して、Oracle Internet Directoryでそれらのネーミング・コンテキストを公開する必要があります。

関連項目:

ネーミング・コンテキストの公開方法は、「Oracle Internet Directoryでのネーミング・コンテキストの管理」を参照してください

3.7 Oracle Internet Directoryでのセキュリティ機能

Oracle Internet Directoryは、Oracle Identity Managementの重要な要素です。これを使用すると、複数のOracleコンポーネントをOracle Internet Directoryの共有インスタンスに対して機能するようにデプロイできます。この共有により、企業はすべてのアプリケーションでセキュリティ管理を単純化できます。

Oracle Identity Managementインフラストラクチャで果たす役割に加えて、Oracle Internet Directoryは情報を保護するための多数の強力な機能を提供します。

Oracle Internet Directory自体に、次のようなセキュリティ機能があります。

  • Secure Sockets Layer: 伝送中にデータが変更、削除または再現されていないことを保証します。

  • データ・プライバシ: データがOracle Internet Directoryに格納されている間に不適切に参照されていないことを保証します

  • パスワード・ポリシー: パスワードの定義方法と使用方法に関する規則を確立し、適用することを保証します。

  • 認可:ユーザーが権限を持つ情報のみを読み取りまたは更新することを保証します。

  • パスワード保護: 第三者がパスワードを簡単に解読できないことを保証します。

  • 認証: ユーザー、ホストおよびクライアントのアイデンティティが正しく検証されていることを保証します。

これらの機能をすべて使用して、Oracle Internet Directoryを使用できる複数のアプリケーションに一貫したセキュリティ・ポリシーを適用できます。企業またはホスティングされた環境ではこのようにすることをお薦めします。このためには、管理業務の委任を行うためのディレクトリをデプロイします。このデプロイメントによって、たとえば、グローバル管理者は、部門にあるアプリケーションのメタデータに対するアクセスをその部門の管理者に委任できます。その結果、部門の管理者が自部門のアプリケーションへのアクセスを制御できるようになります。

基礎となるOracle Databaseのセキュリティ機能(透過的データ暗号化、Database Vaultなど)を使用しても、Oracle Internet Directoryデータを保護できます。

関連項目:

拡張管理: セキュリティ

3.8 グローバリゼーション・サポート

Oracle Internet Directoryは、LDAPバージョン3国際化(I18N)規格に準拠しています。この規格では、ディレクトリ・データを格納するデータベースでUnicode Transformation Format 8-bit(UTF-8)文字セットを使用する必要があります。Oracle9iでは、AL32UTF8と呼ばれる新しいUTF-8文字セットを追加しました。このデータベース文字セットは、最新の補助文字を含む最新バージョンのUnicode(3.2)をサポートしています。これにより、Oracle Internet Directoryは、Oracleグローバリゼーション・サポートがサポートするほとんどすべての言語の文字データを格納できます。また、Oracle Internet Directoryの実装では異なるApplication Program Interface(API)がいくつか含まれていますが、Oracle Internet Directoryでは、各APIに正しい文字エンコーディングが使用されることを保証しています。

グローバリゼーション・サポートとは、シングルバイト文字とマルチバイト文字の双方をサポートすることを意味します。シングルバイト文字は、1バイトのメモリーで表されます。たとえば、ASCIIテキストはシングルバイト文字を使用します。一方、マルチバイト文字は、複数バイトで表すことができます。たとえば、簡体字中国語はマルチバイト文字を使用します。簡体字中国語のディレクトリ・エントリ定義のASCII表現は次のとおりです。

dn: o=\274\327\271\307\316\304,c=\303\300\271\372
objectclass: top
objectclass: organization
o: \274\327\271\307\316\304

属性値は、簡体字中国語のディレクトリ・エントリ定義のASCII表現に対応します。

デフォルトでは、Oracle Internet Directoryの主なコンポーネントであるOIDモニター(OIDMON)、OID制御ユーティリティ(OIDCTL)、Oracleディレクトリ・サーバー(OIDLDAPD)およびOracleディレクトリ・レプリケーション・サーバー(OIDREPLD)は、UTF-8文字セットのみを使用します。Oracle文字セット名はAL32UTF8です。

Oracleディレクトリ・サーバーとデータベース・ツールの実行をUTF8データベース上に限定していた、従来の制限はなくなりました。ただし、Oracle Internet Directoryサーバーの基礎となるデータベースがAL32UTF8またはUTF8でない場合は、クライアント文字セットにあるすべての文字(文字コードが同じかどうかにかかわらず)がデータベース文字セットに含まれていることを確認する必要があります。そうでない場合は、クライアント・データをデータベース文字セットにマップできないと、LDAPの追加、削除、変更または識別名の変更の各操作でデータが消失する可能性があります。

Oracle Directory Services Managerは、Unicode(固定幅の16ビットUnicodeであるUTF-16)を使用します。国際化文字セットをサポートできます。

関連項目:

3.9 分散ディレクトリの理解

オンライン・ディレクトリは論理的に集中管理されていますが、物理的には複数のサーバーに分散できます。この分散によって、サーバーが1つのみの場合に実行する必要のある作業が削減され、ディレクトリにより多くのエントリを格納できるようになります。分散ディレクトリは、レプリケートまたはパーティション化できます。情報がレプリケートされると、同じネーミング・コンテキストが複数のサーバーに格納されます。情報がパーティション化されると、他と重複しない1つ以上のネーミング・コンテキストが各ディレクトリ・サーバーに格納されます。分散ディレクトリでは、情報の一部がパーティション化されたりレプリケートされたりする場合があります。

この項では、次の項目について説明します。

3.9.1 ディレクトリ・レプリケーション

レプリケーションは、複数のディレクトリ・サーバーに同じネーミング・コンテキストをコピーし、管理するプロセスです。

レプリケーションの概念の詳細は、「Oracle Internet Directoryレプリケーションの理解」を参照してください。

3.9.2 ディレクトリ・パーティション化

パーティション化は、ディレクトリ情報を分散するもう1つの方法です。パーティション化では、他と重複しないネーミング・コンテキストが1つ以上、各ディレクトリ・サーバーに格納されます。

図3-6に、異なるサーバーにいくつかのネーミング・コンテキストが存在している、パーティション化されたディレクトリを示します。

図3-6 パーティション化されたディレクトリ

図3-6の説明が続きます
「図3-6 パーティション化されたディレクトリ」の説明

図3-6では、サーバーAに次の4つのネーミング・コンテキストが存在しています。

  • dc=acme,dc=com

  • c=us,dc=acme,dc=com

  • c=uk,dc=acme,dc=com

  • c=au,dc=acme,dc=com

サーバーAにある次の2つのネーミング・コンテキストは、サーバーBにレプリケートされています。

  • dc=acme,dc=com

  • c=au,dc=acme,dc=com

ディレクトリは、サーバーBにリクエストした情報がサーバーAに常駐している場合に、1つ以上のナレッジ参照を使用して情報を検索します。この情報を参照形式でクライアントに渡します。

3.10 ナレッジ参照と参照

ナレッジ参照は、別のパーティションに保持されている様々なネーミング・コンテキストの名前とアドレスを提供します。

たとえば、図3-6で、サーバーBは、ナレッジ参照を使用して、サーバーA上のネーミング・コンテキストc=usとc=ukを指し示します。サーバーBがサーバーAに常駐している情報の要求を受けると、サーバーBは1つ以上のサーバーAへの参照を返します。クライアントは、これらの参照を使用してサーバーAと通信できます。

一般的に、各ディレクトリ・サーバーには、上位ナレッジ参照と従属ナレッジ参照の両方があります。上位ナレッジ参照では、DIT内でルートに向かう上位方向が指し示されます。この参照は、パーティション化されたネーミング・コンテキストをその親に結び付けます。従属ナレッジ参照では、DIT内で他のパーティションへの下位方向が指し示されます。

たとえば、図3-7では、サーバーBに4つのネーミング・コンテキストがあり、そのうちの2つは他のネーミング・コンテキストの上位にあります。この2つの上位ネーミング・コンテキストは、従属ナレッジ参照を使用して、その従属ネーミング・コンテキストを指し示しています。逆に、サーバーA上のネーミング・コンテキストは、サーバーBに直属の上位ネーミング・コンテキストを持っています。したがって、サーバーAは、上位ナレッジ参照を使用してサーバーB上の親を指し示しています。

図3-7 ナレッジ参照を使用したネーミング・コンテキストの指示

この図については本文で説明しています。

当然のことですが、DITの最上位で始まるネーミング・コンテキストは、上位ネーミング・コンテキストへのナレッジ参照を持つことはできません。

ノート:

  • ナレッジ参照の有効性を実施するためのインターネット規格は現在存在せず、Oracle Internet Directoryでも同様です。管理者が、エンタープライズ・ネットワーク内の複数のナレッジ参照間の一貫性を確保する必要があります。

  • ナレッジ参照エントリの管理権限は、スキーマやアクセス制御などの他の重要な権限管理機能と同様に制限することをお薦めします。

参照には次の2つの種類があります。

  • スマート参照

    これらは、ナレッジ参照エントリが検索の有効範囲内にあるときにクライアントに返されます。リクエストされた情報が格納されているサーバーをクライアントに示します。

    たとえば、次のような場合があります。

    • サーバーAには、ネーミング・コンテキストou=server development,c=us,o=acmeがあり、さらにサーバーBへのナレッジ参照があります。

    • サーバーBには、ネーミング・コンテキストou=sales,c=us,o=acmeがあります。

    ou=sales,c=us,o=acmeにある情報のリクエストを、クライアントがサーバーAに送信すると、サーバーAはサーバーBへの参照をユーザーに提供します。

  • デフォルト参照

    デフォルト参照は、ベース・オブジェクトがディレクトリになく、さらに操作が別のサーバー上のネーミング・コンテキストで実行されたときに返されます。デフォルト参照では、通常、ディレクトリ・パーティション化配置に関するより多くの情報を持つサーバーにクライアントを送信します。

    たとえば、サーバーAが次のものを保持するとします。

    • ネーミング・コンテキストc=us,o=acme

    • ディレクトリ・パーティション化配置全般についてより多くのナレッジを持つサーバーPQRへのナレッジ参照

    クライアントがc=uk,o=acmeにある情報をリクエストしたとします。サーバーAは、c=uk,o=acmeネーミング・コンテキストを持っていないことを認識すると、そのクライアントにサーバーPQRへの参照を提供します。クライアントは、リクエストしたネーミング・コンテキストを保持しているサーバーをそこから検索できます。

    関連項目:

    ナレッジ参照と参照の管理

3.11 サービス・レジストリとサービス・ツー・サービス認証

サービス・レジストリおよびサービス・ツー・サービス認証フレームワークとはOracle Internet Directoryの機能であり、サービスを相互にリクエストするOracleテクノロジ・コンポーネント間の統合を促進します。サービス・レジストリは、コンポーネントが互いに検出できるように情報の格納場所を提供します。サービス・ツー・サービス認証フレームワークは、一方のコンポーネントから他方のコンポーネントを認証できるようにして、互いの信頼関係を確立します。

サービス・レジストリとはOracle Internet Directoryの(cn=Services, Cn=OracleContextの下にある)コンテナであり、コンポーネントがプロトコルやサービス・タイプなどの接続情報を格納する場所です。インストールの際、それぞれのOCSコンポーネントがこのレジストリに情報を登録します。実行時には、このコンポーネントが他のコンポーネントの登録情報を検出します。サービス・レジストリ・オブジェクトは、Oracle Internet DirectoryのDITで、rootOracleContextのコンポーネント固有のサービス・コンテナに格納されます。

サービス・ツー・サービス認証は、一方のサービスから他方のサービスを認証できるようにして、サービス間の信頼関係を確立するフレームワークです。インストールの際、各クライアント・サービスにはOracle Internet Directoryのユーザー名とパスワードがプロビジョニングされます。さらに、それぞれのターゲット・サービスがOracle Internet Directoryでの権限ロールを定義して、どのコンポーネントを信頼すべきかを制御します。一方のコンポーネントが他方のコンポーネントのサービスをリクエストする場合、リクエスト側は独自のアイデンティティと資格証明を使用して、他のクライアントと同様にターゲット・サービスに対して認証する必要があります。またリクエスト・サービスは、ターゲット・サービスのトラステッド・アプリケーション・グループにリスト表示される必要があります(デフォルト・グループは対比アプリケーション、カウンターポイズ、cn=OracleContextです)。さらにリクエスト・サービスは、ターゲット・サービスがユーザーも認証できるように、ユーザーのアイデンティティを送信する必要があります。このデータは、Digest認証もしくはターゲット・サービスに備わっているセキュア認証のいずれかにより、安全に送信されます。

3.12 Oracleディレクトリ統合プラットフォーム

Oracle Directory Integration Platformを使用して、企業はアプリケーションやその他のディレクトリをOracle Internet Directoryに統合できます。これは、Oracle Internet Directoryのデータとエンタープライズ・アプリケーションや接続ディレクトリのデータとの一貫性を維持するために必要なすべてのインタフェースとインフラストラクチャを提供します。また、サード・パーティ・ベンダーや開発者にとっては、独自の接続エージェントの開発とデプロイが容易になります。

たとえば、企業では人事管理データベースの従業員レコードとOracle Internet Directoryとの同期が必要な場合があります。また、変更がOracle Internet Directoryに適用されるたびに通知が必要なLDAP対応のアプリケーション(Oracle Portalなど)がデプロイされている可能性もあります。

統合の性質に基づいて、Oracle Directory Integration Platformは2つの異なるサービスを提供します。

  • 同期化統合サービスは、接続ディレクトリと中央のOracle Internet Directoryとの一貫性を維持します

  • プロビジョニング統合サービスは、ユーザーやグループなど、重要なエントリに対する変更を反映するために、ターゲット・アプリケーションに通知を送信します

    関連項目:

    『Oracle Directory Integration Platformの管理』の同期、プロビジョニングおよびその違いに関する項。

3.13 Oracle Internet Directoryでのアイデンティティ管理のロールの理解

Oracle Internet Directoryでのアイデンティティ管理のロールおよびそのレルムについて理解します。

この項では、次の項目について説明します。

3.13.1 アイデンティティ管理

アイデンティティ管理とは、通常は、組織のアプリケーション・ユーザーの管理です。セキュリティ・ライフサイクルのステップには、アカウント作成、一時停止、権限変更、アカウント削除があります。管理対象エンティティには、デバイス、プロセス、アプリケーション、ネットワーク環境で対話するために必要なその他のものも含まれます。組織外のユーザー、たとえば顧客、取引先、Webサービスなども含まれることがあります。

アイデンティティ管理は、管理コストを削減すると同時にセキュリティを向上できるため、ITデプロイメントにとって重要です。

Oracle Identity Management製品によって、企業内のすべてのエンタープライズ・アイデンティティと各種アプリケーションに対するそのアクセスを集中的かつ安全に管理するためのデプロイメントが可能になります。アイデンティティ管理は、次のタスクで構成されています。

  • 企業規模の単一コンソールを使用したエンタープライズ・アイデンティティの作成およびアイデンティティの共有プロパティの管理

  • エンタープライズ・アイデンティティのグループの作成

  • 企業で利用できる各種サービスでのこれらのアイデンティティのプロビジョニング。これには、次のものが含まれます。

    • アカウント作成

    • アカウント一時停止

    • アカウント削除

  • これらのアイデンティティに関連付けられたポリシーの管理。これには次のものがあります。

    • 認可ポリシー

    • 認証ポリシー

    • 既存アイデンティティに委任された権限

ノート:

Oracle Identity Managementの詳細および追加リソースは、Oracle Technology Network (OTN) Webサイト(http://www.oracle.com/technetwork/index.html)を参照してください。

3.13.2 アイデンティティ管理レルムの理解

アイデンティティ管理レルムおよびアイデンティティ管理ポリシーのコンテキストの説明について理解します。

この項では、次の項目について説明します。

3.13.2.1 アイデンティティ管理レルム

アイデンティティ管理レルムは、あるアイデンティティ管理ポリシーがデプロイメントにより定義され、施行される企業内での有効範囲を定義します。次で構成されています。

  • 有効範囲の定義されたエンタープライズ・アイデンティティの集合(USドメインのすべての従業員など)。

  • これらのアイデンティティに関連付けられたアイデンティティ管理ポリシーの集合。アイデンティティ管理ポリシーの例としては、すべてのユーザー・パスワードに少なくとも1文字の英数字を含む必要があることなどがあります。

  • グループの集合、すなわちアイデンティティの集約。アイデンティティ管理ポリシーの設定を簡素化します。

同じOracle Identity Managementインフラストラクチャ内で複数のアイデンティティ管理レルムを定義できます。複数のレルムによって、ユーザーの集団を区別し、各レルムで異なるアイデンティティ管理ポリシー(パスワード・ポリシー、ネーミング・ポリシー、自己変更ポリシーなど)を施行できます。

各アイデンティティ管理レルムには、他のレルムと区別するために固有の名前が付けられます。また、レルムに対して完全な管理制御を行うために、レルム固有の管理者も決められます。

3.13.2.2 デフォルトのアイデンティティ管理レルム

機能するすべてのOracleコンポーネントに対して、アイデンティティ管理レルムが必要です。Oracle Internet Directoryのインストール中に作成される特別なレルムは、デフォルトのアイデンティティ管理レルムと呼ばれます。レルムの名前が指定されていない場合に、Oracleコンポーネントがユーザー、グループおよび関連付けられたポリシーを検索する場所です。

デフォルトのアイデンティティ管理レルムは、ディレクトリに1つのみです。デプロイメントに、複数のアイデンティティ管理レルムが必要である場合、その1つをデフォルトとして選択する必要があります。

3.13.2.3 アイデンティティ管理ポリシー

Oracle Identity Managementインフラストラクチャは、一連の柔軟な管理ポリシーをサポートします。これは、次の要素で構成されます。

  • ディレクトリ構造ポリシーとネーミング・ポリシー。これにより次のことが可能になります。

    • デプロイメントにあわせてOracle Internet Directoryのディレクトリ構造をカスタマイズ。

    • 各種アイデンティティが置かれる場所と、それを一意に識別する方法を指定

  • Oracle Identity Managementインフラストラクチャによりサポートされる認証方式とプロトコルを指定できる認証ポリシー

  • 権限のある特定のサービスへのアクセスを制御し、必要に応じて管理を委任できるアイデンティティ管理認可

    ノート:

    Oracle Internet Directoryリリース9.0.2で使用した「サブスクライバ」は、「アイデンティティ管理レルム」と同じ用語です。

3.14 TCPキープ・アライブ・メカニズム

Oracle Internet Directoryでは、TCPキープ・アライブ・メカニズムがオペレーティング・システム・レベルで有効化されている場合、デフォルトでTCPキープ・アライブがサポートされます。特定のOracle Internet Directory構成は不要です。

ただし、Oracle Virtual DirectoryがOracle Internet Directoryサーバーとともに構成されている場合、TCPキープ・アライブは、リスナー(LDAPクライアントの接続先)とアダプタ(Oracle Internet Directoryまたは他のLDAPサーバー)間で分割されます。この使用例では、次の構成が必要です。

  • オペレーティング・システム・レベルで、TCPキープ・アライブ・メカニズムを有効化します。

  • Oracle Virtual Directoryで、vde.soTimeoutBackend JVMパラメータを設定し、接続をクローズする前にOracle Virtual DirectoryがOracle Internet Directoryからのレスポンスを待機する時間を指定します。つまり、このパラメータによって、パラメータで指定された時間の経過後に非アクティブなソケットをクローズするようにOracle Virtual Directoryに指示します。

    vde.soTimeoutBackendパラメータを構成すると、リモート・クライアントまたはサーバー障害が原因で孤立してしまったサーバー接続をOracle Virtual Directoryが検出して安全にクローズするために役立ちます。これによって、サーバーのパフォーマンスが大幅に向上します。

    vde.soTimeoutBackendパラメータの値は、次のようにJava APIを使用して作成されたソケットに渡されます。 

    public void setSoTimeout(int timeout) 
                throws SocketException

    前述の方法では、timeout制限パラメータ(ミリ秒単位)を指定してSO_TIMEOUTを有効または無効にできます。このオプションを0以外のタイム・アウトに設定すると、このSocketに関連付けられたInputStreamのread()呼出しが、その時間の間だけブロックされます。タイム・アウトの期限が切れると、Socketがまだ有効であってもjava.net.SocketTimeoutExceptionが発行されます。このオプションは、ブロック処理に入る前に有効にしておく必要があります。タイムアウトは0より大きい値を指定する必要があります。タイム・アウト0は無限のタイム・アウトとして解釈されます。

3.15 リソース情報の概念の理解

次のトピックでは、コンテキストの説明やリソース情報のコンポーネント、およびこれらのコンポーネントが配置されているDIT内の場所について理解します。

Oracleコンポーネントの中には、ユーザーのリクエストを実行するために、様々なリポジトリおよびサービスからデータを収集するものがあります。データを収集するために、これらのコンポーネントでは次の情報が必要です。

  • データの収集元となるリソースのタイプを指定する情報。たとえば、Oracle Databaseなどです。これは、リソース・タイプ情報と呼ばれます。

  • リソースに対するユーザーの接続および認証のための情報。これは、リソース・アクセス情報と呼ばれます。

各項では、次のトピックについて説明します。

3.15.1 リソース・タイプ情報

ユーザーのリクエストを処理するためにアプリケーションが使用するリソースの情報をリソース・タイプ情報と呼びます。リソース・タイプには、Oracle DatabaseやプラガブルなJava Database Connectivityデータ・ソースなどがあります。リソース・タイプ情報には、ユーザーの認証に使用するクラス、ユーザー識別子、パスワードなどの項目が含まれます。

Oracle Internet Directoryセルフサービス・コンソールを使用して、リソース・タイプ情報を指定します。

3.15.2 リソース・アクセス情報

データベースに対するユーザーの接続および認証に関する情報は、リソース・アクセス情報と呼ばれます。これは、様々なOracleコンポーネントで取得および共有できるリソース・アクセス記述子(RAD)と呼ばれるエントリに格納されます。

たとえば、販売レポートに関するユーザーのリクエストを処理するために、Oracle Reportsは複数のデータベースに問い合せます。データベースへの問合せでは、次の処理が実行されます。

  1. RADからの必要な接続情報の取得

  2. 取得した情報を使用した、データベースへの接続およびデータをリクエストしているユーザーの認証

この処理が終了すると、レポートがコンパイルされます。

Oracle Internet Directoryセルフサービス・コンソールを使用して、リソース・アクセス情報を指定します。リソース・アクセス情報をユーザーごとに指定することも、すべてのユーザーに共通に指定することもできます。後者の場合、指定されたアプリケーションに接続するすべてのユーザーは、デフォルトで同じ情報を使用して必要なデータベースに接続します。たとえば、各ユーザーが一意のシングル・サインオン・ユーザー名でアプリケーション内に定義されている場合など、アプリケーションに独自の統合アカウント管理がある場合は、デフォルトのリソース・アクセス情報を定義することをお薦めします。

3.15.3 DIT内のリソース情報の位置

次に示す図および説明から、DIT内のリソース情報を検索する方法について理解します。

図3-8に、DIT内のリソース情報の位置を示します。

図3-8 DIT内のリソース・アクセス情報およびリソース・タイプ情報の配置

この図については本文で説明しています。

図3-8に示すとおり、リソース・アクセス情報およびリソース・タイプ情報は、Oracleコンテキストに格納されます。

各ユーザーのリソース・アクセス情報は、Oracleコンテキスト内のcn=User Extensionsノードに格納されます。この例では、cn=User Extensionsノードには、デフォルトのユーザーおよび特定のユーザーの両方のリソース・アクセス情報が含まれています。後者の場合、リソース・アクセス情報には、SalesデータベースおよびBugデータベースの両方へのアクセスで必要な情報が含まれます。

各アプリケーションのリソース・アクセス情報は、アプリケーション名で識別されるオブジェクトに格納されます。この例では、cn=Oracle Reports Services, cn=Products,cn=Oracle Context,dc=us,dc=acme,dc=comです。これは、その製品に固有のユーザー情報です。

リソース・タイプ情報は、コンテナcn=resource types, cn=common,cn=products,cn=Oracle Contextに格納されます。

関連項目:

  • エンド・ユーザーによるリソース・アクセス情報の指定手順は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Managementリファレンス』にある、自身のリソース情報の管理、ユーザー・エントリの作成、デフォルト・リソースの構成および新規リソース・タイプの作成に関する項を参照してください

  • 『Oracle Identity Managementリファレンス』のプラグイン・スキーマ要素に関する項

  • 『Oracle Reports ServicesレポートWeb公開ガイド』の拡張配布の作成に関する項