| Oracle Fusion Middleware Oracle Internet Directory管理者ガイド 11gリリース1（11.1.1） B55919-01 |
|
 戻る |
 次へ |
この章では、Oracle Internet Directoryの基本要素の概念およびOracle Internet Directoryのアーキテクチャについて説明します。
この章の項目は次のとおりです。
この項の項目は次のとおりです。
Oracle Internet Directoryのノードは、同じディレクトリ・ストアに接続された1つ以上のディレクトリ・サーバー・インスタンスで構成されます。ディレクトリ・ストア（ディレクトリ・データのリポジトリ）は、Oracle Databaseです。
|
注意: 同じドメイン内のすべてのOracle Internet Directoryインスタンスは、同じOracle Databaseに接続します。 |
図3-1に、単一ノード上で稼働している様々なディレクトリ・サーバー要素と、それらの関係を示します。
Oracleデータベース・サーバーと次のものとの接続には、いずれもOracle Net Servicesが使用されます。
Oracleディレクトリ・サーバー非SSLポート（デフォルトでは3060）
Oracleディレクトリ・サーバーSSL対応ポート（デフォルトでは3131）
OIDモニター
LDAPは、ディレクトリ・サーバーと次のものとの間の接続に使用されます。
Oracle Directory Services Manager
Oracleディレクトリ・レプリケーション・サーバー
Oracleディレクトリ・サーバー・インスタンスとOracleディレクトリ・レプリケーション・サーバーは、オペレーティング・システム経由でOIDモニターに接続します。
図3-1に示すとおり、Oracle Internet Directoryのノードには、次の主なコンポーネントがあります。
表3-1 Oracle Internet Directoryのノード
Oracleディレクトリ・レプリケーション・サーバーはLDAPを使用して、Oracleディレクトリ（LDAP）サーバー・インスタンスと通信します。データベースとの通信には、すべてのコンポーネントがOCI/Oracle Net Servicesを使用します。Oracle Directory Services Managerとコマンドライン・ツールは、LDAPを介してOracleディレクトリ・サーバーと通信します。
図3-2に、LDAPサーバー・インスタンスとも呼ばれる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
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の範囲のポートを試します。
ディレクトリ・メタデータは、ディレクトリ・サーバーが実行中にLDAPリクエストを処理するために使用する情報です。ディレクトリ・メタデータは、基礎となるデータ・リポジトリに格納されます。起動中に、ディレクトリ・サーバーはこの情報を読み取り、ローカル・メタデータ・キャッシュに格納します。ディレクトリ・サーバーは、実行中にこのキャッシュを使用し、受信するLDAP操作リクエストを処理します。
ディレクトリ・サーバーのローカル・メタデータ・キャッシュには、次の種類のメタデータが格納されます。
ディレクトリ・サーバーによりサポートされるオブジェクト・クラス、属性、一致規則の定義。ディレクトリ・サーバーは、ディレクトリ・オブジェクトの作成および変更時にこの情報を使用します。ディレクトリ・オブジェクトとは、オブジェクト・クラスおよびそれに関連付けられた属性と一致規則の集合です。第19章「ディレクトリ・スキーマの管理」を参照してください。
アクセス制御ポリシー・ポイント（ACP）
ドメインにある情報へのアクセスを定義し、制御するためのディレクトリ管理ドメイン。ディレクトリ・サーバーは、特定のLDAP操作をユーザーが実行できるかどうかを判断するときにACPを使用します。第28章「ディレクトリ・アクセス制御の管理」を参照してください。
ルートDSE（ディレクトリ・サービス・エージェント固有のエントリ）には、ディレクトリ・サーバー自体に関する情報を格納する複数の属性が入っています。これらの属性には次のような情報項目が含まれます。
ネーミング・コンテキスト識別名
サブ・スキーマ・サブエントリ識別名
上位参照（参照）識別名
Oracle Internet Directory構成コンテナやレジストリ・コンテナのような特殊なエントリ識別名
変更ログ・コンテナや変更ステータス・コンテナのような特殊なエントリ識別名
レプリケーション承諾コンテナの識別名
「DSEの属性」を参照してください。
アクセス制御ポリシーで使用できるグループ。
ディレクトリ・スキーマは、標準のgroupofuniquenamesオブジェクト・クラスとgroupofnamesオブジェクト・クラスによってディレクトリ・グループ・オブジェクトをサポートします。これらのオブジェクト・クラスは、配布リストやメーリング・リストのようなグループに関する情報を格納します。
Oracle Internet Directoryは、 orclprivilegegroupと呼ばれる補助オブジェクト・クラスによって、これらの標準グループ・オブジェクトを拡張します。このオブジェクト・クラスは、アクセス制御ポリシーで使用できる権限グループをサポートし、ユーザーのグループに対するアクセスの許可や拒否を柔軟に行えるようにします。ディレクトリ・サーバーはこの情報を次の場合に使用します。
特定のユーザーに関してサブスクライブされた権限グループを検索するためのLDAPバインド操作
権限が付与されたグループに対するアクセスを許可または拒否するディレクティブがポリシーにあるかどうかのアクセス制御ポリシーの評価
基礎となるデータベースで索引付けされた属性に関する情報を入れる特別なエントリ。ディレクトリは、ディレクトリ検索操作中にこの情報を使用します。「属性の索引付けの概要」を参照してください。
ホスティングされた企業に関する情報を入れる特別なエントリ。ホスティングされた企業とは、別の企業からサービスを提供される企業のことをいいます。このエントリのメタデータには、ホスティングされた企業の識別名、ユーザー検索ベース、ニックネームなどの属性が入っています。詳細は、第32章「レルムの計画、デプロイおよび管理」を参照してください。
プラグイン・イベントをトリガーする操作の種類と、操作のどの時点でそのプラグインをトリガーするかに関する情報を入れる特別なエントリ。この詳細は、第41章「Oracle Internet Directoryサーバー・プラグインの開発」を参照してください。
暗号タイプと検証属性タイプに関する情報を入れる特別なエントリ。この詳細は、第29章「パスワード・ベリファイアの管理」を参照してください。
ユーザー・パスワード資格証明についてディレクトリ・サーバーにより施行されるポリシーに関する情報の入った、1つ以上の特別なエントリ。ディレクトリ・サーバーは、パスワード・ポリシーを施行するために実行時にこの情報を使用します。第27章「パスワード・ポリシーの管理」を参照してください。
この例では、Oracle Internet Directoryがどのように検索リクエストを処理するかを示します。
ユーザーまたはクライアントが検索リクエストを入力します。検索条件は、次の1つ以上のオプションによって決まります。
SSL: クライアントとサーバーは、SSLの暗号化と認証またはSSLの暗号化のみを使用するセッションを確立できます。SSLが使用されていない場合、クライアントのメッセージは平文で送信されます。
ユーザーのタイプ: ユーザーは、要求する機能の実行に必要な権限を持っているかどうかによって、特定のユーザーまたは匿名ユーザーのいずれかでディレクトリへのアクセスを要求できます。
フィルタ: ユーザーは、1つ以上の検索フィルタを使用して検索条件を絞り込むことができます。検索フィルタには、ブール条件and、or、notの他に、greater than、equal to、less thanなどの演算子を使用するものがあります。
C APIは、LDAPプロトコルを使用して、ディレクトリへの接続リクエストをディレクトリ・サーバー・インスタンスに送信します。
ディレクトリ・サーバーはユーザーを認証します。このプロセスはバインドと呼ばれます。ディレクトリ・サーバーは、アクセス制御リスト（ACL）もチェックして、そのユーザーが、リクエストした検索の実行を許可されているかどうかを検証します。
ディレクトリ・サーバーは、LDAPからの検索リクエストをOracle Call Interface（OCI）およびOracle Net Servicesに変換し、Oracle Databaseに送信します。
Oracle Databaseは、情報を取得し、その情報をディレクトリ・サーバー、C API、クライアントの順に返します。
|
注意: 検索フィルタに指定できる属性の最大数は255です。 |
オンライン・ディレクトリでは、オブジェクトに関する情報の集合はエントリと呼ばれます。エントリには、社員、会議室、E-Commerceパートナ、プリンタなどの共有ネットワーク・リソースに関する情報などが含まれます。
この項の項目は次のとおりです。
オンライン・ディレクトリ内の各エントリは、識別名（DN）で一意に識別されます。識別名は、ディレクトリ階層におけるそのエントリの位置を正確に伝えます。この階層は、ディレクトリ情報ツリー（DIT）で示されます。
識別名とディレクトリ情報ツリーとの関係を理解するには、図3-3を参照してください。
図3-3のDITは、Acme Corporationに所属する、Anne Smithという同名の2人の従業員のエントリを示しています。この図のディレクトリ情報ツリーは、地理的および組織的な系統に従って構造化されています。左のブランチのAnne Smithは米国のSales部門に勤務し、もう一方のAnne Smithは英国のServer Development部門に勤務しています。
右のブランチの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人いる可能性がある場合は、一意の識別番号で各従業員を識別するなど、補助的な方法を使用してください。
エントリに対して迅速で効率的な操作を行うために、Oracle Internet Directoryはエントリ・キャッシングを使用します。この機能を有効にした場合、Oracle Internet Directoryは、各エントリに一意の識別子を割り当て、指定された数の識別子をキャッシュ・メモリーに格納します。ユーザーがエントリに対する操作を行うと、ディレクトリ・サーバーは、キャッシュ内でエントリ識別子を検索し、対応するエントリをディレクトリから取得します。この方法によって、Oracle Internet Directoryのパフォーマンスが強化されます。小規模から中規模の企業では特に有効です。
|
注意: 単一サーバー、単一インスタンスのOracle Internet Directoryノードの場合にのみ、エントリ・キャッシングを使用できます。 |
一般的な電話帳の場合、個人に関するエントリには住所や電話番号などの情報項目が含まれます。オンライン・ディレクトリでは、このような情報項目は属性と呼ばれます。一般的な従業員エントリの属性には、役職名、電子メール・アドレス、電話番号などがあります。
たとえば、図3-4では、英国（uk）のAnne Smithに関するエントリには、その個人の固有な情報を提供する各種の属性があります。これらの属性はツリーの右側の円の中に示されています。emailaddrs、printername、jpegPhotoおよびapp preferencesなどがあります。さらに、図3-4の各黒丸も属性を持つエントリですが、ここではそれぞれの属性は示されていません。
各属性は、属性タイプと1つ以上の属性値で構成されます。属性タイプとは、その属性に含まれている情報の種類（jobTitleなど）です。属性値は、そのエントリで表される情報の具体的な内容です。たとえば、jobTitle属性に対する値にはmanagerがあります。
この項の項目は次のとおりです。
属性には2種類の情報があります。
アプリケーション属性
この情報は、ディレクトリ・クライアントによってメンテナンスおよび取得が行われ、ディレクトリの操作には影響しません。例として電話番号があります。
システム構成属性
この情報は、ディレクトリ自体の操作に関係します。一部の操作情報は、サーバーを制御するためにディレクトリによって指定されます。たとえば、エントリの作成や変更のタイムスタンプ、エントリを作成または変更したユーザーの名前などです。アクセス情報などのその他の操作情報は、管理者が定義し、ディレクトリ・プログラムで処理時に使用されます。
エントリをディレクトリに追加すると、エントリの検索能力を強化するために、Oracle Internet Directoryが自動的にいくつかのシステム構成属性を作成します。次のポリシーが含まれます。
ユーザーがエントリを変更すると、Oracle Internet Directoryでは自動的にmodifiersName属性がエントリを変更したユーザーの名前に、modifyTimestamp属性がUTCで表したエントリ変更時間にそれぞれ更新されます。
属性は、単一値または複数値のいずれかです。単一値の属性には1つの値のみ設定でき、複数値の属性には複数の値を設定できます。複数値の属性の例には、グループ全員の名前を載せたグループ・メンバーシップ・リストがあります。
Oracle Internet Directoryは、標準的なLDAP属性をすべて実装しています。表3-3に、Internet Engineering Task Force（IETF）のRFC 2798に定義されている、一般的なLDAP属性の一部を示します。
表3-3 一般的なLDAP属性
| 属性タイプ | 属性の文字列 | 説明 |
|---|---|---|
|
|
エントリの一般的な名前（ |
|
|
domainComponent |
ドメイン・ネーム・システム（DNS）にあるコンポーネントの識別名（ |
|
|
|
JPEGフォーマットの写真イメージ。バイナリ形式で格納されます。 |
|
|
|
組織の名前（ |
|
|
|
組織内の単位の名前（ |
|
|
owner |
|
エントリの所有者を識別する名前（ |
|
surname、sn |
|
ユーザーの姓（ |
|
telephoneNumber |
電話番号（ |
|
関連項目: Oracle Internet Directoryが提供するいくつかの属性のリストは、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』のOracle Identity Management LDAP属性のリファレンスを参照してください。 |
属性の構文とは、各属性にロード可能なデータの形式です。たとえば、telephoneNumber属性の構文の場合、電話番号は空白やハイフンを含む一続きの数値である必要があります。しかし、別の属性の構文では、そのデータを日付書式で表すか、または数値のみで表すかの指定が必要な場合もあります。各属性の構文は必ず1つのみです。
Oracle Internet Directoryは、Internet Engineering Task Force（IETF）のRFC 2252で指定されているほとんどの構文を認識するため、そのドキュメントに記述されている構文の大部分を属性に関連付けることができます。Oracle Internet Directoryは、RFC 2252構文の認識に加え、一部のLDAP構文も適用します。Oracle Internet Directoryですでにサポートされているこれらの構文以外に、新規の構文を追加することはできません。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』のLDAP属性の構文に関する項 |
ディレクトリ・サーバーは、クライアントのリクエストに応じて、検索と比較の操作を実行します。この操作時に、ディレクトリ・サーバーは関連する一致規則を調査し、検索対象の属性値と、格納されている属性値との間の等価性を判断します。たとえば、telephoneNumber属性に関連付けられた一致規則では、(650) 123-4567を(650) 123-4567または6501234567のいずれか、あるいはその両方と一致させることができます。属性の作成時に、属性を一致規則と関連付けます。
Oracle Internet Directoryは、標準的なLDAP一致規則をすべて実装しています。Oracle Internet Directoryですでにサポートされているこれらの一致規則に、新規の一致規則を追加することはできません。
|
関連項目:
|
属性タイプには様々なオプションがあり、検索または比較操作でその属性の値をどのように使用できるかを指定できます。たとえば、ある従業員がロンドンとニューヨークという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は不適切です。 |
オブジェクト・クラスは、エントリの構造を定義する属性のグループです。ディレクトリ・エントリを定義するときは、1つ以上のオブジェクト・クラスを割り当てます。これらのオブジェクト・クラスの属性には、必須で値を指定する必要があるものもあれば、オプションで値を指定しなくてよいものもあります。
たとえば、organizationalPersonオブジェクト・クラスには、必須属性のcommonName（cn）とsurname（sn）が含まれています。また、オプション属性として、telephoneNumber、uid、streetAddressおよびuserPasswordが含まれています。organizationalPersonオブジェクト・クラスを使用してエントリを定義するときは、commonName（cn）およびsurname（sn）に値を指定する必要があります。ただし、telephoneNumber、uid、streetAddressおよびuserPasswordに値を指定する必要はありません。
この項の項目は次のとおりです。
サブクラスは、別のオブジェクト・クラスから導出されたオブジェクト・クラスです。サブクラスが導出されるオブジェクト・クラスは、そのスーパークラスと呼ばれます。たとえば、オブジェクト・クラスorganizationalPersonは、オブジェクト・クラスpersonのサブクラスです。逆に、オブジェクト・クラスpersonは、オブジェクト・クラスorganizationalPersonのスーパークラスです。
サブクラスは、そのスーパークラスの属性をすべて継承します。たとえば、サブクラスorganizationalPersonは、そのスーパークラスpersonの属性を継承しています。エントリも、そのスーパークラスが継承した属性を継承します。
|
注意: オブジェクト・クラス自体に値は含まれていません。値を持つのは、オブジェクト・クラスのインスタンス、つまりエントリのみです。サブクラスがスーパークラスから属性を継承するときは、スーパークラスの属性定義のみを継承します。 |
topと呼ばれる、スーパークラスを持たない特別なオブジェクト・クラスが1つあります。このオブジェクト・クラスは、ディレクトリ内のすべてのオブジェクト・クラスのスーパークラスの1つで、その属性定義はすべてのエントリに継承されます。
オブジェクト・クラスには次の3つの型があります。
構造型
補助型
抽象型
構造型オブジェクト・クラスは、オブジェクトの基本的側面を記述します。使用するオブジェクト・クラスの大部分は構造型オブジェクト・クラスであり、すべてのエントリは少なくとも1つの構造型オブジェクト・クラスに属している必要があります。構造型オブジェクト・クラスの例としては、personやgroupOfNamesがあります。
これらのオブジェクト・クラスは、実社会のエンティティと、その物理的属性および論理的属性をモデルとしています。たとえば、人、プリンタ、データベース接続などがあります。
構造型オブジェクト・クラスは、構造規則を使用して、特定のオブジェクト・クラスの下に作成可能なオブジェクトの種類に制限を与えます。たとえば、構造規則では、organization（o）オブジェクト・クラスの下にあるすべてのオブジェクトはorganizational unit（ou）であることが要求されます。この規則に従うと、personオブジェクトをorganizationオブジェクト・クラスのすぐ下に入力することはできません。同様に、構造規則では、personオブジェクトの下にorganizational unit（ou）オブジェクトを置くことはできません。
補助型オブジェクト・クラスは、オプションの属性をグループ化したもので、エントリ内の既存の属性リストを拡張します。構造型オブジェクト・クラスと異なり、エントリを格納する場所に関する制限はなく、DITでのエントリの位置に関係なく、任意のエントリに置くことができます。
抽象型オブジェクト・クラスは、仮想のオブジェクト・クラスです。これは、オブジェクト・クラス階層の最上位レベルを指定する際にのみ使用されます。エントリに対する唯一のオブジェクト・クラスにはできません。たとえば、オブジェクト・クラスtopは抽象型オブジェクト・クラスです。これは、構造型オブジェクト・クラスすべてに対するスーパークラスとして必要ですが、単独では使用できません。
topオブジェクト・クラスには、必須属性であるobjectClassの他に、次のオプション属性があります。top内のオプション属性は次のとおりです。
ディレクトリ・ネーミング・コンテキストは、全体が1つのサーバーに存在するサブツリーです。これは完全なサブツリーである必要があります。つまり、サブツリーの最上位の役割を果すエントリから始まり、下位のリーフ・エントリまたは従属ネーミング・コンテキストへの参照へと伸びていく必要があります。そのサイズは、単一のエントリからディレクトリ情報ツリー（DIT）全体まで様々です。
図3-5に、適切なネーミング・コンテキストと不適切なネーミング・コンテキストを示します。左側の適切なコンテキストは連続しており、右側の不適切なコンテキストは連続していないことに注意してください。
ユーザーが特定のネーミング・コンテキストを検出できるようにするには、ldapmodifyを使用して、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データを保護できます。
Oracle Internet Directoryは、LDAPバージョン3国際化（I18N）規格に準拠しています。この規格では、ディレクトリ・データを格納するデータベースでUTF-8（Unicode Transformation Format 8-bit）キャラクタ・セットを使用する必要があります。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）を使用します。Oracle Directory Services Managerは国際化キャラクタ・セットをサポートできます。
|
関連項目:
|
オンライン・ディレクトリは論理的に集中管理されていますが、物理的には複数のサーバーに分散できます。この分散によって、サーバーが1つのみの場合に実行する必要のある作業が削減され、ディレクトリにより多くのエントリを格納できるようになります。
分散ディレクトリは、レプリケートまたはパーティション化できます。情報がレプリケートされると、同じネーミング・コンテキストが複数のサーバーに格納されます。情報がパーティション化されると、他と重複しない1つ以上のネーミング・コンテキストが各ディレクトリ・サーバーに格納されます。分散ディレクトリでは、情報の一部がパーティション化されたりレプリケートされたりする場合があります。
この項の項目は次のとおりです。
レプリケーションは、複数のディレクトリ・サーバーに同じネーミング・コンテキストをコピーし、管理するプロセスです。レプリケーションの概念については、第6章「Oracle Internet Directoryレプリケーションの理解」 を参照してください。
パーティション化は、ディレクトリ情報を分散するもう1つの方法です。パーティション化では、他と重複しないネーミング・コンテキストが1つ以上、各ディレクトリ・サーバーに格納されます。
図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-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上の親を指し示しています。
当然のことですが、DITの最上位で始まるネーミング・コンテキストは、上位ネーミング・コンテキストへのナレッジ参照を持つことはできません。
スマート参照
これらは、ナレッジ参照エントリが検索の有効範囲内にあるときにクライアントに返されます。スマート・ナレッジ参照は、リクエストされた情報が格納されているサーバーをクライアントに示します。
たとえば、次のような場合があります。
サーバー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への参照を提供します。クライアントは、リクエストしたネーミング・コンテキストを保持しているサーバーをそこから検索できます。
Oracle Delegated Administration Servicesは、ユーザーのかわりにディレクトリ操作を実行するために事前定義されたWebベースのユニットのセットです。この一連のサービスは、ディレクトリ管理者が他の管理者やエンド・ユーザーに対して特定の機能を委任できるようにすることによって、ディレクトリ管理の日常的な作業からディレクトリ管理者を解放します。この一連のサービスによって、ディレクトリ対応アプリケーションに必要な大部分の機能が提供されます。たとえば、ユーザー・エントリの作成、グループ・エントリの作成、エントリの検索、ユーザー・パスワードやその他の従業員固有のデータの変更などがあります。
|
注意: この章で言及するOracle Delegated Administration Servicesはすべて、Oracle Delegated Administration Services 10g（10.1.4.3.0）以上のことです。 |
Oracle Delegated Administration Servicesを使用して、ディレクトリ内のアプリケーション・データを管理するための独自のツールを開発できます。また、Oracle Internet Directoryセルフサービス・コンソールを使用することもできます。これは、Oracle Internet Directoryに含まれるOracle Delegated Administration Servicesに基づいたツールです。このコンソールは、委任管理を提供するためにいくつかのOracleコンポーネントで使用されます。
|
関連項目: 10g（10.1.4.0.1）ライブラリの『Oracle Identity Management委任管理ガイド』。 |
サービス・レジストリおよびサービス・ツー・サービス認証フレームワークとは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認証もしくはターゲット・サービスに備わっているセキュア認証のいずれかにより、安全に送信されます。
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 Fusion Middleware Oracle Identity Management統合ガイド』 |
この項の項目は次のとおりです。
アイデンティティ管理とは、通常は、組織のアプリケーション・ユーザーの管理です。セキュリティ・ライフサイクルの手順には、アカウント作成、一時停止、権限変更、アカウント削除があります。管理対象エンティティには、デバイス、プロセス、アプリケーション、ネットワーク環境で対話するために必要なその他のものも含まれます。組織外のユーザー、たとえば顧客、取引先、Webサービスなども含まれることがあります。
アイデンティティ管理は、管理コストを削減すると同時にセキュリティを向上できるため、ITデプロイメントにとって重要です。
Oracle Identity Management製品によって、企業内のすべてのエンタープライズ・アイデンティティと各種アプリケーションに対するそのアクセスを集中的かつ安全に管理するためのデプロイメントが可能になります。アイデンティティ管理は、次のタスクで構成されています。
企業規模の単一コンソールを使用したエンタープライズ・アイデンティティの作成およびアイデンティティの共有プロパティの管理
エンタープライズ・アイデンティティのグループの作成
企業で利用できる各種サービスでのこれらのアイデンティティのプロビジョニング。次のサービスが含まれます。
アカウント作成
アカウント一時停止
アカウント削除
これらのアイデンティティに関連付けられたポリシーの管理。次のポリシーが含まれます。
認可ポリシー
認証ポリシー
既存アイデンティティに委任された権限
Oracle Identity Management製品には、次のものがあります。
Oracle Internet Directory: Oracle Databaseに実装されたスケーラブルで堅牢なLDAPバージョン3準拠のディレクトリ・サービスです。
Oracle Virtual Directory: 固有の位置にあるデータを同期化または移動せずに複数のデータ・ソースにアクセスできます。Oracle Virtual Directoryは、アプリケーション固有のアイデンティティ・データのビューを複数提供できます。Oracle Virtual Directoryを使用することにより、アプリケーション固有のソースに対するデータ・アクセスを保護し、既存のデータ・ソースの可用性を高めることもできます。
Oracle Directory Integration Platform: Oracle Internet Directoryと他のディレクトリおよびユーザー・リポジトリを同期化します。
Oracle Delegated Administration Services: ユーザーおよびアプリケーション管理者による、信頼できるプロキシ・ベースのディレクトリ情報管理を提供します。（Oracle Internet Directory 11gリリース1（11.1.1）はOracle Single Sign-On 10g（10.1.4.3.0）以上と互換性があります。）
Oracle Single Sign-On: Oracleアプリケーションとサード・パーティのWebアプリケーションへのシングル・サインオン・アクセスを提供します。（Oracle Internet Directory 11gリリース1（11.1.1）はOracle Delegated Administration Services 10g（10.1.4.3.0）以上と互換性があります。）
Oracle Identity Federation: 規格への準拠と相互運用性が実証されたスケーラブルなアーキテクチャを備えるスタンドアロン・アプリケーションの使用しやすさと移植性の両方を合せた自己完結型のフェデレーション・ソリューションを提供します。
Oracle Identity Manager: エンタープライズ・アプリケーションと管理対象システムへのアクセス権限を自動的に付与および取り消すプロビジョニング・システムです。
Oracle Role Manager: ビジネスおよび組織的な関係、ロールおよび資格を管理するエンタープライズ規模のアプリケーションです。
Oracle Enterprise Single Sign-On: メインフレーム、クライアント/サーバーおよびWebアプリケーションに対してエンタープライズ認証とシングル・サインオンを提供する、アクセス管理システムです。
Oracle Access Manager: デジタル・アイデンティティを構成し、主にWeb上にある異機種環境の保護されたアプリケーションおよびコンテンツへのアクセスを制御する管理システムです。
Oracle Adaptive Access Manager: Webアクセスにおけるリアルタイムな詐欺検出と企業向けのマルチファクタ・オンライン認証セキュリティを提供するソリューションです。
Oracle Entitlements Server: アプリケーション開発者が、アプリケーション内部に以前に組み込まれた詳細認可ポリシーを外部化し、一元化できるようにします。
Oracle Authentication Services for Operating Systems: Oracle Internet Directoryを使用してLinuxおよびUNIXシステム上のユーザー・アイデンティティの格納、認証および管理を一元化できます。
Oracle Identity Managementは、Oracle製品のためのエンタープライズ・インフラストラクチャを提供するために設計されたものですが、ユーザー作成アプリケーションおよびサード・パーティのエンタープライズ・アプリケーションのために、汎用のアイデンティティ管理ソリューションとしても使用できます。サード・パーティのアプリケーション、ハードウェア、およびネットワーク・オペレーティング・システムのために、堅牢でスケーラブルな企業全体のアイデンティティ管理プラットフォームを提供します。カスタム・アプリケーションは、一連のドキュメント化され、サポートされるサービスや、APIによりOracle Identity Managementを活用できます。次のようなサービスがあります。
Oracle Internet Directoryは、C、JavaおよびPL/SQLのためのLDAP APIを提供します。他のLDAP SDKと互換性があります。
Oracle Delegated Administration Servicesは、サード・パーティのアプリケーションをサポートするようにカスタマイズできるコア・セルフサービス・コンソールを提供します。また、ディレクトリ・データを操作するカスタマイズされた管理インタフェースを構築するためのいくつかのサービスも提供します。
Oracle Directory Synchronization Serviceは、Oracle Internet Directoryとサード・パーティ・ディレクトリおよび他のユーザー・リポジトリとの同期のためのカスタム・ソリューションの開発とデプロイメントを容易にします。
Oracle Directory Integration Platformは、サード・パーティのアプリケーションをプロビジョニングし、Oracle環境を他のプロビジョニング・システムと統合できます。
Oracle Single Sign-Onは、他のOracle Webアプリケーションとシングル・サインオン・セッションを共有するパートナ・アプリケーションを開発およびデプロイするためのAPIを提供します。
また、オラクル社はサード・パーティのアプリケーション・ベンダーと共同で、それらのアプリケーションがOracle Identity Managementを直接活用できるようにしています。
アイデンティティ管理レルムは、あるアイデンティティ管理ポリシーがデプロイメントにより定義され、施行される企業内での有効範囲を定義します。次の要素で構成されます。
有効範囲が定義されたエンタープライズ・アイデンティティの集合。たとえば、USドメインの全従業員などです。
これらのアイデンティティに関連付けられたアイデンティティ管理ポリシーの集合。アイデンティティ管理ポリシーの例としては、すべてのユーザー・パスワードに少なくとも1文字の英数字を含む必要があることなどがあります。
グループの集合、すなわちアイデンティティの集約。アイデンティティ管理ポリシーの設定を簡素化します。
同じOracle Identity Managementインフラストラクチャ内で複数のアイデンティティ管理レルムを定義できます。複数のレルムによって、ユーザーの集団を区別し、各レルムで異なるアイデンティティ管理ポリシー（パスワード・ポリシー、ネーミング・ポリシー、自己変更ポリシーなど）を施行できます。
各アイデンティティ管理レルムには、他のレルムと区別するために固有の名前が付けられます。また、レルムに対して完全な管理制御を行うために、レルム固有の管理者も決められます。
すべてのOracleコンポーネントが機能するには、アイデンティティ管理レルムが必要です。Oracle Internet Directoryのインストール中に作成される特別なレルムは、デフォルトのアイデンティティ管理レルムと呼ばれます。これは、レルムの名前が指定されていない場合に、Oracleコンポーネントが、ユーザー、グループおよび関連付けられたポリシーを検索する場所です。
デフォルトのアイデンティティ管理レルムは、ディレクトリに1つのみです。デプロイメントに、複数のアイデンティティ管理レルムが必要である場合、その1つをデフォルトとして選択する必要があります。
Oracle Identity Managementインフラストラクチャは、一連の柔軟な管理ポリシーをサポートします。これは、次の要素で構成されます。
ディレクトリ構造ポリシーとネーミング・ポリシー。これにより次のことが可能になります。
デプロイメントに合せてOracle Internet Directoryのディレクトリ構造をカスタマイズ
各種アイデンティティが置かれる場所と、それを一意に識別する方法を指定
Oracle Identity Managementインフラストラクチャによりサポートされる認証方式とプロトコルを指定できる認証ポリシー
権限のある特定のサービスへのアクセスを制御し、必要に応じて管理を委任できるアイデンティティ管理認可
|
注意: Oracle Internet Directoryリリース9.0.2で使用した「サブスクライバ」は、「アイデンティティ管理レルム」と同じ用語です。 |
Oracleコンポーネントの中には、ユーザーのリクエストを実行するために、様々なリポジトリおよびサービスからデータを収集するものがあります。データを収集するために、これらのコンポーネントでは次の情報が必要です。
データの収集元となるリソースのタイプを指定する情報。たとえば、Oracle Databaseなどです。これは、リソース・タイプ情報と呼ばれます。
リソースに対するユーザーの接続および認証のための情報。これは、リソース・アクセス情報と呼ばれます。
この項の項目は次のとおりです。
ユーザーのリクエストを処理するためにアプリケーションが使用するリソースの情報をリソース・タイプ情報と呼びます。リソース・タイプには、Oracle DatabaseやプラッガブルなJava Database Connectivityデータ・ソースなどがあります。リソース・タイプ情報には、ユーザーの認証に使用するクラス、ユーザー識別子、パスワードなどの項目が含まれます。
Oracle Internet Directoryセルフサービス・コンソールを使用して、リソース・タイプ情報を指定します。
データベースに対するユーザーの接続および認証に関する情報を、リソース・アクセス情報と呼びます。この情報は、様々なOracleコンポーネントで取得および共有できるリソース・アクセス記述子（RAD）と呼ばれるエントリに格納されます。
たとえば、販売レポートに関するユーザーのリクエストを処理するために、Oracle Reportsは複数のデータベースに問い合せます。データベースへの問合せでは、次の処理が実行されます。
RADからの必要な接続情報の取得
取得した情報を使用した、データベースへの接続およびデータをリクエストしているユーザーの認証
この処理が終了すると、レポートがコンパイルされます。
Oracle Internet Directoryセルフサービス・コンソールを使用して、リソース・アクセス情報を指定します。リソース・アクセス情報をユーザーごとに指定することも、すべてのユーザーに共通に指定することもできます。後者の場合、指定されたアプリケーションに接続するすべてのユーザーは、デフォルトで同じ情報を使用して必要なデータベースに接続します。たとえば、各ユーザーが一意のシングル・サインオン・ユーザー名でアプリケーション内に定義されている場合など、アプリケーションに独自の統合アカウント管理がある場合は、デフォルトのリソース・アクセス情報を定義することをお薦めします。
図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に格納されます。
