| Oracle Fusion Middleware Oracle Internet Directory管理者ガイド 11g リリース1(11.1.1) B55919-02 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle Internet Directory管理者ガイド 11g リリース1(11.1.1) B55919-02 |
|
前 |
次 |
この章では、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操作リクエストを処理します。
|
注意: メタデータ・キャッシュはライトスルー・キャッシュです。LDAP操作では、最初にデータベースに書き込み、次に対応するキャッシュ・エントリを無効化します。このエントリをその後検索すると、キャッシュがリフレッシュされます。 |
ディレクトリ・サーバーのローカル・メタデータ・キャッシュには、次の種類のメタデータが格納されます。
ディレクトリ・サーバーによりサポートされるオブジェクト・クラス、属性、一致規則の定義。ディレクトリ・サーバーは、ディレクトリ・オブジェクトの作成および変更時にこの情報を使用します。ディレクトリ・オブジェクトとは、オブジェクト・クラスおよびそれに関連付けられた属性と一致規則の集合です。第20章「ディレクトリ・スキーマの管理」を参照してください。
アクセス制御ポリシー・ポイント(ACP)
ドメインにある情報へのアクセスを定義し、制御するためのディレクトリ管理ドメイン。ディレクトリ・サーバーは、特定のLDAP操作をユーザーが実行できるかどうかを判断するときにACPを使用します。第29章「ディレクトリ・アクセス制御の管理」を参照してください。
ルートDSE(ディレクトリ・サービス・エージェント固有のエントリ)には、ディレクトリ・サーバー自体に関する情報を格納する複数の属性が入っています。これらの属性には次のような情報項目が含まれます。
ネーミング・コンテキスト識別名
サブ・スキーマ・サブエントリ識別名
上位参照(参照)識別名
Oracle Internet Directory構成コンテナやレジストリ・コンテナのような特殊なエントリ識別名
変更ログ・コンテナや変更ステータス・コンテナのような特殊なエントリ識別名
レプリケーション承諾コンテナの識別名
「DSEの属性」を参照してください。
アクセス制御ポリシーで使用できるグループ。
ディレクトリ・スキーマは、標準のgroupofuniquenamesオブジェクト・クラスとgroupofnamesオブジェクト・クラスによってディレクトリ・グループ・オブジェクトをサポートします。これらのオブジェクト・クラスは、配布リストやメーリング・リストのようなグループに関する情報を格納します。
Oracle Internet Directoryは、 orclprivilegegroupと呼ばれる補助オブジェクト・クラスによって、これらの標準グループ・オブジェクトを拡張します。このオブジェクト・クラスは、アクセス制御ポリシーで使用できる権限グループをサポートし、ユーザーのグループに対するアクセスの許可や拒否を柔軟に行えるようにします。ディレクトリ・サーバーはこの情報を次の場合に使用します。
特定のユーザーに関してサブスクライブされた権限グループを検索するためのLDAPバインド操作
権限が付与されたグループに対するアクセスを許可または拒否するディレクティブがポリシーにあるかどうかのアクセス制御ポリシーの評価
基礎となるデータベースで索引付けされた属性に関する情報を入れる特別なエントリ。ディレクトリは、ディレクトリ検索操作中にこの情報を使用します。「属性の索引付けの概要」を参照してください。
ホスティングされた企業に関する情報を入れる特別なエントリ。ホスティングされた企業とは、別の企業からサービスを提供される企業です。このエントリのメタデータには、ホスティングされた企業の識別名、ユーザー検索ベース、ニックネームなどの属性が入っています。詳細は、第33章「レルムの計画、デプロイおよび管理」を参照してください。
プラグイン・イベントをトリガーする操作の種類と、操作のどの時点でそのプラグインをトリガーするかに関する情報を入れる特別なエントリ。この詳細は、第43章「Oracle Internet Directoryサーバー・プラグインの開発」を参照してください。
暗号タイプと検証属性タイプに関する情報を入れる特別なエントリ。この詳細は、第30章「パスワード・ベリファイアの管理」を参照してください。
ユーザー・パスワード資格証明についてディレクトリ・サーバーにより施行されるポリシーに関する情報の入った、1つ以上の特別なエントリ。ディレクトリ・サーバーは、パスワード・ポリシーを施行するために実行時にこの情報を使用します。第28章「パスワード・ポリシーの管理」を参照してください。
この例では、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は、米国の販売部門に勤務しています。もう一方の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人いる可能性がある場合は、一意の識別番号で各従業員を識別するなど、補助的な方法を使用してください。
エントリに対して迅速で効率的な操作を行うために、Oracle Internet Directoryはエントリ・キャッシングを使用します。この機能を有効にした場合、Oracle Internet Directoryは、各エントリに一意の識別子を割り当て、指定された数の識別子をキャッシュ・メモリーに格納します。ユーザーがエントリに対する操作を行うと、ディレクトリ・サーバーは、キャッシュ内でエントリ識別子を検索し、対応するエントリをディレクトリから取得します。この方法によって、Oracle Internet Directoryのパフォーマンスが強化され、特に小規模から中規模の企業で有効となります。
|
注意:
|
一般的な電話帳の場合、個人に関するエントリには住所や電話番号などの情報項目が含まれます。オンライン・ディレクトリでは、このような情報項目は属性と呼ばれます。一般的な従業員エントリの属性には、役職名、電子メール・アドレス、電話番号などがあります。
たとえば、図3-4では、英国(uk)のAnne Smithのエントリには、複数の属性が含まれており、それぞれ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に定義されている、一般的なもののいくつかを示します。
表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)規格に準拠しています。この規格では、ディレクトリ・データを格納するデータベースで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)を使用します。国際化キャラクタ・セットをサポートできます。
|
関連項目:
|
オンライン・ディレクトリは論理的に集中管理されていますが、物理的には複数のサーバーに分散できます。この分散によって、サーバーが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 Directory Integration Platform管理者ガイド |
この項の項目は次のとおりです。
アイデンティティ管理とは、通常は、組織のアプリケーション・ユーザーの管理です。セキュリティ・ライフサイクルの手順には、アカウント作成、一時停止、権限変更、アカウント削除があります。管理対象エンティティには、デバイス、プロセス、アプリケーション、ネットワーク環境で対話するために必要なその他のものも含まれます。組織外のユーザー、たとえば顧客、取引先、Webサービスなども含まれることがあります。
アイデンティティ管理は、管理コストを削減すると同時にセキュリティを向上できるため、ITデプロイメントにとって重要です。
Oracle Identity Management製品によって、企業内のすべてのエンタープライズ・アイデンティティと各種アプリケーションに対するそのアクセスを集中的かつ安全に管理するためのデプロイメントが可能になります。アイデンティティ管理は、次のタスクで構成されています。
企業規模の単一コンソールを使用したエンタープライズ・アイデンティティの作成およびアイデンティティの共有プロパティの管理
エンタープライズ・アイデンティティのグループの作成
企業で利用できる各種サービスでのこれらのアイデンティティのプロビジョニング。次のサービスが含まれます。
アカウント作成
アカウント一時停止
アカウント削除
これらのアイデンティティに関連付けられたポリシーの管理。次のポリシーが含まれます。
認可ポリシー
認証ポリシー
既存アイデンティティに委任された権限
Oracle Identity Management製品には、次のものがあります。
Oracle Internet Directory: Oracle Databaseに実装されたスケーラブルで堅牢なLDAPバージョン3準拠のディレクトリ・サービスです。
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に格納されます。
