| Oracle Access Managerインストレーション・ガイド 10g（10.1.4.3） B55482-01 |
|
 戻る |
 次へ |
この章では、Oracle Virtual Directoryを使用してOracle Access Managerを実装し、Data Anywhereを有効化する方法に焦点を当てます。ここでは、次の項目について説明します。
Oracle Access ManagerとOracle Virtual Directoryの実装では、Oracle Virtual Directoryの機能のサブセットのみが使用されます。このため、この章で説明するOracle Access Manager固有の構成に、Oracle Virtual Directoryのドキュメントに記載されているすべての情報が適用されるわけではありません。
この章は、次のマニュアルとともに使用する必要があります。
『Oracle Virtual Directory and Virtual Directory Manager Installation Guide』
『Oracle Virtual Directory製品マニュアル』
Oracle Virtual Directoryは、複数のデータ・ソースのユーザー・データを結合し、集約された仮想ディレクトリを作成します。
Oracle Access Managerアプリケーションからは、仮想ディレクトリはその他のLDAPディレクトリと同じように動作しているように見えます。また、通常、Oracle Access Managerユーザーには、Oracle Access Managerによって取得されたデータが異機種間ソースのものであると明白に示されることはありません。
ターゲット・データ・ストアの所有者から見ると、Oracle Virtual Directoryの影響はほとんどありません。つまり、データ・ストアの所有者がデータの所有権を放棄することもなく、Oracle Virtual Directoryがネイティブ・データ構造の形式を変更したり、元のデータのコピーを永続的に保持することもありません。
Oracle Access Managerの特定の機能を有効化するには、ターゲットLDAPディレクトリのスキーマを拡張するか、仮想ディレクトリに含まれるプライマリ・データベース表に、Oracle Access Managerの補助ユーザー属性をシミュレートする列を追加する必要があります。詳細は、「スキーマ拡張の概要」を参照してください。
|
注意: Oracle Virtual Directoryを使用したOracle Access Manager実装は、ユーザー・プロファイルおよびグループ・リポジトリとともに使用することを目的としています。ただし、この実装は、ポリシー・ルールやワークフローなどのOracle Access Managerのメタデータはサポートしていません。このメタデータは、公認のLDAPv3ディレクトリ（Oracle Internet Directory、SunまたはMicrosoft Active Directoryなど）に格納する必要があります。 |
Oracle Access ManagerとOracle Virtual Directoryの実装に関わる論点を正確に説明するために、このドキュメントでは、次の用語を非常に特殊な意味で使用します。
仮想ディレクトリ: 複数のソースから取り出されたユーザー・データを表す論理的な集約ディレクトリで、これらすべてのデータが、顧客が定義したスキーマが一律に適用されている標準LDAPディレクトリから発生したかのように見えます。Oracle Access Manager実装の趣旨上、Oracle Virtual Directoryではネイティブ・データ・ソースの範囲外でユーザー・プロファイルの永続的なコピーは作成されません。むしろ、Oracle Virtual Directoryは、各ユーザー・プロファイルをOracle Access Managerアプリケーションがリクエストしたとおりに取得および変換します。
仮想ディレクトリは、1つの連続した検索ベースとして、または複数の非結合検索ベースとして構成できます。詳細は、「検索ベースのオプションの概要」を参照してください。
スーパー・ディレクトリ: ネームスペース・マッピングを容易にするための特別なタイプの仮想ディレクトリです。このディレクトリには、フェデレートされたLDAPディレクトリ、RDBMSデータベースおよび埋込み仮想データ・ソースの組合せを含めることができます。埋込み仮想データ・ソースは、分割プロファイル、ネイティブRDBMS結合およびネイティブRDBMSビューになります。複数のデータ・ストアから集約される1つの連続した検索ベースを作成するためにサポートされている唯一の方法であるスーパー・ディレクトリは、Oracle Virtual Directoryローカル・ストア・アダプタを使用してOracle Access Managerに接続します。
フェデレーション: Oracle Access ManagerからOracle Virtual Directoryを介して参照する仮想ディレクトリのデータ・ソースを認識できるようにする方法です。特定のユーザー・プロファイルに関するデータはすべて、LDAPディレクトリ、単一表データベースまたは埋込み仮想データ・ソースなどの1つのデータ・ストアから作成されます。
様々なユーザー・プロファイルが様々なフェデレーテッド・データ・ストアから作成されますが、これらのデータ・ストアには、次のタイプのデータ・ソースが組み合されています。
複数の異機種間LDAPディレクトリ
すべてのユーザー・データを単一表に格納する複数のリレーショナル・データベース
次の3つのカテゴリに分けられる埋込み仮想データ・ソース
ディレクトリとデータベースの組合せが含まれる分割プロファイル
複数のデータベース表が含まれるネイティブRDBMSビュー
複数のデータベース表が含まれるネイティブRDBMS結合
詳細は、「フェデレーテッド・データ・ストア」を参照してください。
埋込み仮想データ・ソース: Oracle Virtual Directoryがターゲット・データ・ストアとして認識する仮想オブジェクトであり、Oracle Access Managerから参照したり、仮想ディレクトリでフェデレートした後Oracle Access Managerから参照できます。各埋込み仮想データ・ストアは、2つ以上のターゲット・データ・ストアを集約します。埋込み仮想データ・ストアには、次の3つのタイプがあります。
分割プロファイル
ネイティブRDBMS結合
ネイティブRDBMSビュー
通常、埋込み仮想データ・ストアは認証および認可アクティビティのみに適しています。これは、これらのアクティビティにセカンダリ・データ・ソースが必ず含まれているためです。セカンダリ・データ・ソースは、一連のID管理アクティビティでは使用できない場合があります。
分割プロファイル: 複数のデータ・ソースから作成された特別なタイプの埋込み仮想データ・ソースです。分割プロファイルには、LDAPディレクトリや複数のデータベース表を含む複数のソースから各ユーザーのユーザー・プロファイル属性が取り出されます。
各データ・ストアは、Oracle Virtual Directory仮想ディレクトリにマップされるユーザー・プロファイル属性のセットを完成するために必要な属性の一部を提供します。これらの属性は、LDAPディレクトリまたはデータベース表から取得できます。Oracle Access Managerのすべての操作をセカンダリ・ストア内の属性で実行できるとはかぎらないため、Oracle Access Managerのユーザー属性はすべて、プライマリ・データ・ストアに存在する必要があります。Oracle Access Managerは、Oracle Virtual Directoryを介して分割プロファイルを標準LDAPディレクトリとして認識します。また、分割プロファイルは、仮想ディレクトリの一部としてフェデレートすることもできます。
詳細は、「分割プロファイル」および「図10-8 Oracle Virtual Directoryの実装レイヤー」を参照してください。
単一表データベース: 単一表データベースは、必ずしも1つの表のみを含むデータベースを指すのではなく、最上位の仮想ディレクトリにマップされるすべてのユーザー・プロファイル属性を1つの表のみに格納するデータベースを指します。
複数表データベース: 仮想ディレクトリにマップされるユーザー・プロファイル属性を1つ以上の表に格納するデータベースです。
仮想ディレクトリ・スキーマ: Oracle Access ManagerがOracle Virtual Directoryを介して参照する最上位ディレクトリで使用するために顧客が開発するスキーマです。このスキーマは、Oracle Access Managerの属性を使用して拡張する必要があります。詳細は、「仮想ディレクトリ・スキーマ」を参照してください。
必要に応じて、ターゲット・データ・ソースから取り出された顧客属性を使用して仮想ディレクトリ・スキーマをさらに拡張することもできます。詳細は、「顧客スキーマ」を参照してください。
仮想ディレクトリのテクノロジにより、次の4つの主要な機能についてOracle Access Managerの機能が拡張されます。
フェデレーテッド・データ・ストア: 前述の「フェデレーテッド・データ・ストア」を参照してください。
分割プロファイル: 前述の「分割プロファイル」を参照してください。
集約ネームスペース: ターゲット・データ・ストアと埋込み仮想データ・ソースをスーパー・ディレクトリのノードにマップします。スーパー・ディレクトリを作成するには、ローカル・ストア・アダプタをインストールする必要があります。詳細は、「集約ネームスペース」を参照してください。
スキーマ・マッピング: 最上位の仮想ディレクトリの顧客が定義したスキーマに応じてすべてのターゲット・データ・ストアからデータを変換します。詳細は、「集約スキーマ・マッピング」を参照してください。
仮想ディレクトリの一般的な利点に関する背景的な詳細は、『Oracle Virtual Directory製品マニュアル』を参照してください。
Oracle Virtual Directoryを使用すると、Oracle Access Managerユーザーは、ユーザー・アカウントが一律に体系化された1つのデータ・ソースのものであるかのように、複数の異なるソースのユーザー・データにアクセスして操作できるようになります。ホスト・ディレクトリ・サーバーの各ベンダーが異なり、様々なスキーマが採用されていても、Oracle Virtual Directoryは複数のLDAPディレクトリからユーザー・データを取り込むことができます。図10-1は、Oracle Access Managerが複数のLDAPディレクトリに接続する方法を示します。
図10-1 フェデレーテッドLDAPディレクトリがあるOracle Virtual Directory実装
図10-1は、1つのディレクトリ（Oracle Virtual Directory）を参照することにより、サポートされているLDAP v3ディレクトリ・サーバー（Microsoft、Novell、Sun、Oracle Internet DirectoryおよびIBM）の組合せにアクセスしているOracle Access Managerを示しています。
また、Oracle Virtual Directory仮想ディレクトリには、すべてのユーザー・データを単一表に格納するRDBMSデータベースを組み込むこともできます。複数の表にまたがるユーザー・データの統合の詳細は、「分割プロファイル」を参照してください。
図10-2は、Oracle Access Managerが複数のリレーショナル・データベースに接続する方法を示しています。「データベースの接続性に関するヒント」も参照してください。
図10-2 フェデレーテッドRDBMSアプリケーションが含まれるOracle Virtual Directory実装
図10-2は、Oracle Virtual Directoryディレクトリを参照することにより、Oracle、IBM DB2およびMicrosoft SQL Server RDBMSアプリケーションにアクセスしているOracle Access Managerを示しています。すべてのユーザー・プロファイル属性を単一表に格納するフェデレーテッド・データベースには、完全なアイデンティティ・システムおよびアクセス・システムの機能を使用できます。各メンバー・データベースには、ユーザー・プロファイルの完全なセットが含まれます。
Oracle Access Managerは、Oracle Virtual Directoryを介してターゲット・データ・ストアをフェデレートするために2つのオプションをサポートしています。
非結合検索ベース: Oracle Access Managerが仮想ディレクトリ内の別個の非結合検索ベースとして各データ・ストアを参照できるように、Oracle Virtual Directory実装を構成できます。このような構成の場合、ネームスペースは集約できません。また、各ターゲット・データ・ストアは異なる最上位のマッピング・アダプタの背後にあるため、すべてのデータ・ソースを対象としたグローバルなディレクトリ検索は実行できません。
図10-3は、非結合検索ベース用として構成された仮想ディレクトリを示しています。
図10-3は、Oracle Virtual Directory仮想ディレクトリにアクセスするOracle Access Managerを示しています。仮想ディレクトリは、それぞれがマッピング・アダプタとそのLDAPまたはRDBMSである一連のターゲット・データ・ストアで構成されています。ターゲット・データ・ストアはすべて、顧客が定義した仮想ディレクトリのスキーマにマップされています。Oracle Access Managerは、各ターゲット・データ・ストアを表す非結合検索ベースを参照します。すべてのデータ・ストアを対象としたグローバル検索は実行できません。
統合検索ベース: ローカル・ストア・アダプタを最上位にインストールし、ターゲット・データ・ストアをマップするノードを作成することにより、スーパー・ディレクトリを作成できます。このオプションにより、グローバルなディレクトリ検索と強力なネームスペース集約の両方が可能になります。
図10-4は、連続した統合検索ベースが含まれるスーパー・ディレクトリを示しています。
図10-4は、最上位にローカル・ストア・アダプタがあるスーパー・ディレクトリにアクセスするOracle Access Managerを示しています。スーパー・ディレクトリの各ノードには、マッピング・アダプタとLDAPまたはRDBMSが含まれます。これらは、ローカル・ストア・アダプタを介してOracle Virtual Directoryにアクセスします。Oracle Access Managerは、すべてのターゲット・データ・ストアを対象としてグローバル検索を実行する単一の連続した検索ベースを参照します。この場合、すべてのターゲット・データ・ストアにわたってUIDが一意である必要があります。
Oracle Virtual Directoryを使用すると、Oracle Access Managerユーザーはフェデレーテッド・データ・ストアにアクセスできるだけでなく、LDAPディレクトリやリレーショナル・データベース表などの複数のデータ・ソースからユーザー・プロファイル属性が取り出された仮想分割プロファイル・データ・ソースにもアクセスできるようになります。
たとえば、情報技術によって保守されるActive Directoryアカウントにはユーザーのログイン・パスワードや会社電話番号などの属性を格納するとともに、人事管理によって保守されるリレーショナル・データベース・アカウントには自宅の電話番号や保健プランの加入情報などのその他の属性を格納することが可能です。
このように複数のデータ・ソースに属性を分散するとセカンダリ・データ・ストアで特定のID管理機能を実行できなくなるため、分割プロファイル構成は主に、認証および認可（アクセス・システム）操作に適しています。
図10-5は、分割プロファイルを含む単純な実装を示しています。
図10-5 単純な分割プロファイルを対象としたOracle Access ManagerとOracle Virtual Directoryの実装
図10-5は、単純な分割プロファイルを示しています。Oracle Access ManagerはOracle Virtual Directoryにアクセスし、Oracle Virtual Directoryは結合ビュー・アダプタを使用してプライマリ・データ・ソースとセカンダリ・データ・ソースにアクセスしています。この例では、プライマリ・データ・ソースは従業員ID、従業員名および会社電話番号を提供し、セカンダリ・データ・ソースは保健プラン、退職金プランおよび生命保険プランに関するデータを提供しています。これらの6つの属性が連結され、仮想ディレクトリにマップされています。
プライマリ・データ・ソースにはOracle Access Managerユーザー・ブランチ・スキーマ属性が含まれ、セカンダリ・データ・ソースには通常、顧客属性が含まれます。
アクセス・システムおよびアイデンティティ・システム操作はすべて、プライマリ・データ・ソースの属性に対して実行できます。また、アクセス・システム操作はすべてセカンダリ・ソースのデータに対しても実行できますが、特定のアイデンティティ・システム操作はセカンダリ・データ・ストア内の属性に対して実行できません。
詳細は、「実装の制限」を参照してください。
スーパー・ディレクトリを作成する場合、ID管理とポリシー管理上のニーズに最適のネームスペース階層を指定できます。この新しい階層は、仮想ディレクトリの構成データ・ストアによって使用されるネイティブ・ネームスペース階層とは異なる場合があります。
図10-6に示すように、属性を再編成して新しいレベルに割り当てることができます。
図10-6は、プライマリ・データ・ソースのネームスペースとセカンダリ・データ・ソースのネームスペースのデータにアクセスするスーパー・ディレクトリ・ネームスペースを示しています。この例では、プライマリ・データ・ソースのネームスペースには、WestCoastノードの下にEngineering、MarketingおよびSales属性があるActive Directory Oneが含まれています。同様に、セカンダリ・データ・ソースのネームスペースには、EastCoastノードの下にEngineering、MarketingおよびSales属性があるActive Directory Twoが含まれています。スーパー・ディレクトリ・ネームスペースでは、company、Engineering、WestCoastまたはEastCoastの属性の順に属性が再編成されて割り当てられています。
この例では、Sales、MarketingおよびHuman Resourcesなどの組織がEngineeringのみのポリシーとは無関係である場合、これらの組織はフィルタ処理によって除外できます。以前は、EastCoastまたはWestCoastで分けてポリシーを定義する必要がありました。しかし現在では、仮想ディレクトリにより、すべてのEngineeringというポリシーを1回定義するだけで、EastCoastまたはWestCoastのEngineeringユーザーを網羅できるようになりました。
Oracle Virtual Directory仮想ディレクトリを作成する場合、構成データ・ストアによって使用されるネイティブ・スキーマを、仮想ディレクトリによって使用されるスキーマにマップします。図10-7は、単純なOracle Virtual Directoryシステムにおけるこのマッピングを示しています。
図10-7は、次のデータ・ソースに対する仮想ディレクトリ・スキーマ・マッピングを示しています。
Active Directory: SAMアカウント名、cnおよび電話番号の属性がある、userと呼ばれるオブジェクト・クラスです。
SunOne Directory Server: UID（ユーザーID）、cnおよび電話番号の属性がある、inetorgpersonと呼ばれるオブジェクト・クラスです。
構成データ・ソースのすべての属性には、仮想ディレクトリで対応する属性のデータ型を使用する必要があります。たとえば、仮想ディレクトリ・スキーマの電話番号属性は、リレーショナル・データベースの従業員表の会社電話番号、Active Directoryのuserオブジェクト・クラスの電話番号、およびSunOne Directory Serverのinetorgpersonオブジェクト・クラスの電話番号にマップされます。
Oracle Virtual Directoryにより、Oracle Access Managerの機能は複数の異機種間ディレクトリおよびデータベースに拡張されますが、これにはいくつかの制限があります。Oracle Virtual Directoryを使用してOracle Access Managerをデプロイする場合、このドキュメントに記載されている制限事項に注意する必要があります。表10-1は、制限の対象となる仮想ディレクトリ構成をまとめたもので、これらの問題に関する詳細な説明を示しています。
表10-1 仮想ディレクトリ構成におけるOracle Access Managerの機能の可用性
| データ・ソース | Oracle Access Managerの機能の可用性 | |
|---|---|---|
|
アクセス・ システム |
ID システム |
|
|
フェデレーテッドLDAPディレクトリ |
完全 |
完全 |
|
フェデレーテッド単一表データベース |
完全 |
完全 |
|
フェデレーテッド複数表データベース（ネイティブRDBMS結合機能を使用） |
完全 |
プライマリ・データ・ストアに対しては完全な機能を使用できる。ネイティブRDBMS結合機能がサポートしている場合、セカンダリ・データ・ストアに対して追加、変更および削除機能を使用することもできる。 |
|
フェデレーテッド複数表データベース（ネイティブRDBMSビュー機能を使用） |
完全 |
プライマリ・データ・ストアに対しては完全な機能を使用できるが、セカンダリ・データ・ストアに対して追加および削除機能は使用できない。（セカンダリ・データ・ストアに対して変更機能は使用できる。） |
|
分割プロファイル・ディレクトリ（Oracle Virtual Directoryの結合ビュー・アダプタを使用） |
完全 |
プライマリ・データ・ストアに対しては完全な機能を使用できるが、セカンダリ・データ・ストアに対して追加、変更および削除機能は使用できない。 |
詳細は、次を参照してください。
標準LDAPディレクトリに格納されている個々の属性には、複数の値を使用できます。たとえば、各ユーザーのパスワード履歴を記録したり、LDAPディレクトリに格納されているユーザー・アカウントに複数のサブスクリプションを割り当てることが可能です。
それに対して、SQL準拠のRDBMSアプリケーションで正しく正規化されたデータ表では、1つの表内の同じユーザー属性に複数の値は格納できません。このため、データベース表が含まれるOracle Access ManagerとOracle Virtual Directoryの実装では、多値属性に関する機能のサポートは制限されています。詳細は、オラクル社カスタマ・ケアにお問い合せください。
|
注意: 仮想ディレクトリにLDAPディレクトリのみが組み込まれている場合、多値属性に関する制限は適用されません。 |
仮想ディレクトリに組み込むすべてのデータベース表に単一値属性のみが含まれるかぎり、多くの場合、既存のRDBMSデータベースにすでに格納されているユーザー・プロファイルが完全に単一値属性を使用して実装されているため、制限は適用されません。
まれなケースとして、正規化されていないRDBMSデータ・ストアで多値属性を使用してユーザー・アカウントが実装されている場合、User ManagerおよびGroup Manager操作に関する次の制限に注意すれば、多値属性が含まれるサポート対象外の表を仮想ディレクトリに組み込むことができます。
パスワード履歴機能はサポートされません。
グループごとに複数の管理者は構成できません。
グループごとに複数のサブスクリプションは構成できません。
グループのサブスクリプション通知と登録解除通知のどちらかをアクティブにできますが、両方を同時にアクティブにはできません。
グループごとに複数の動的フィルタは構成できません。
グループごとに複数のグループ・タイプは構成できません。
グループごとに複数のサブスクリプション・タイプは構成できません（使用可能なタイプ: 「オープン」、「閉じる」、「フィルタでオープン」および「ワークフロー経由で制御」）。
仮想ディレクトリのデータベース表には複数の多値属性を含めることはできません。
仮想ディレクトリ用として新しいデータ・ストアを作成する場合、可能であれば必ずLDAPディレクトリを使用することをお薦めします。これは、リレーショナル・データベースが多値属性を処理する能力が制限されているため、ID管理アプリケーションで使用可能な機能が制限されるためです。リレーショナル・データベースに格納されている既存のユーザー・データを処理する場合は、仮想ディレクトリ内での多値属性の処理に関する制限を十分に把握しておいてください。
表10-2は、複数のデータベース表が含まれる埋込み仮想データ・ソースの制限を示しています。
Oracle Access ManagerとOracle Virtual Directoryの実装は、図10-8に示すように、3つのレイヤーで構成されています。
図10-8は、Oracle Virtual Directoryの3つの統合レイヤーを示しています。
Oracle Access Managerレイヤー: このレイヤーには、アイデンティティ・システム、アクセス・システム、およびOracle Access Managerのポリシーおよび構成データ用のディレクトリ・サーバーが含まれます。このレイヤーでは、Oracle Access Managerアプリケーションからは、Oracle Virtual Directoryシステム全体が1つのディレクトリ・サーバーとして見えます。
Oracle Virtual Directoryシステム・レイヤー: このレイヤーには、スーパー・ディレクトリ・オプション用のOracle Virtual Directoryローカル・ストア・アダプタの仮想ディレクトリ・サーバーが含まれます。仮想ディレクトリ・サーバーは、LDAPアダプタおよびRDBMSアダプタにアクセスするために、Oracle Virtual Directory結合ビュー・アダプタを使用します。第3レイヤー（ターゲット・データ・ストア・レイヤー）の対応するターゲット・データ・ストアに接続するために、LDAPアダプタはJNDIドライバを使用し、各RDBMSアダプタは独自のJDBCドライバを使用します。データ・ストアからのスキーマ・マッピングは、LDAPおよびRDBMSアダプタに帰属します。
ターゲット・データ・ストア・レイヤー: このレイヤーには、Oracle Virtual Directoryシステム・レイヤーの対応するLDAPおよびRDBMSアダプタにマップされるLDAPおよびRDBMSデータ・ソースが含まれます。このレイヤーでは、ネイティブ・データの形式はそのままであり、そのソースの所有権も変更されません。
Oracle Access Managerレイヤーのユーザーとアプリケーションには、Oracle Virtual Directoryシステムは、標準スキーマと拡張されたOracle Access Managerの属性が含まれる1つのLDAPディレクトリのように見えます。
仮想ディレクトリ・レイヤー内では、Oracle Virtual Directoryは、Oracle Access Managerアプリケーションによるユーザー・データに対するリクエストを受け入れ、リクエストされたデータを構成データ・ストアから取得し、Oracle Access Managerスキーマに合うようにこのデータを変換し、リクエストしたOracle Access Managerアプリケーションに処理データを戻します。図10-9は、このプロセスの手順を示しています。
図10-9 単純なOracle Access ManagerとOracle Virtual Directoryの実装におけるデータ・リクエストの処理
図10-9は、次のようなデータ・リクエストの処理手順を示しています。
プロセスの概要: リクエストの処理
Oracle Access Managerレイヤーで、アプリケーションは、仮想ディレクトリ・サーバーの情報をリクエストします。
仮想ディレクトリ・レイヤーで、Oracle Virtual Directoryは、リクエストに対応し、仮想ディレクトリ・スキーマのデータをターゲット・データ・ソースによって使用されるスキーマに変換できるアダプタを検索します。
ターゲット・データ・ストア・レイヤーで、ターゲット・データ・ストアでのデータの取得または書込みが行われます。
仮想ディレクトリ・レイヤーで、Oracle Virtual Directoryは、仮想ディレクトリによって使用されるスキーマを適用し、取得したデータを変換します。
Oracle Access Managerレイヤーで、Oracle Virtual Directoryは、リクエストしたOracle Access Managerアプリケーションに変換データを戻します。
Oracle Access ManagerとOracle Virtual Directoryの実装では、ディレクトリまたはデータベースのネイティブ・ネームスペースまたはデータ構造を永続的に変更する必要がないため、ターゲット・データ・ストア・レイヤーのディレクトリおよびデータベースの管理者には、この実装の影響はほとんどないように見えます。
|
注意: 使用する機能によっては、ターゲット・データベース表の列として特定のOracle Access Managerの補助属性を追加する必要がある場合があります。また、Oracle Access Managerスキーマのユーザー・ブランチを使用してターゲットLDAPスキーマを拡張する必要もあります。詳細は、「スキーマ拡張の概要」を参照してください。 |
また、仮想ディレクトリでは、元のデータ所有者の制御が及ばない場所にデータを永続的にコピーする必要はありません。最後に、個々のデータ・ストア以外に個々のユーザー・プロファイルへのアクセスもアイデンティティ・システムの属性アクセス制御を介して制御できるため、データ・セキュリティは保持されるにとどまらずいっそう強化されます。
Oracle Virtual Directoryは、特別なドライバとアダプタを使用して、仮想ディレクトリに組み込むデータ・ソースに接続します。
JNDIドライバ: JNDIドライバは、Oracle Virtual Directoryインストール・パッケージの一部として同梱されています。JNDIドライバはOracle Virtual DirectoryをLDAPディレクトリに接続し、JDBCドライバはOracle Virtual DirectoryをRDBMSソースに接続します。これらのドライバは、Oracle Virtual Directoryをホストするコンピュータにインストールします。
JDBCドライバ: 使用するRDBMSアプリケーションごとに適切なバージョンのJDBCドライバをインストールする必要があります。詳細は、『Oracle Virtual Directory製品マニュアル』と『Oracle Virtual Directory and Virtual Directory Manager Installation Guide』を参照してください。Oracle Virtual Directoryデータベース・アダプタは、JDBCドライバを備えたデータベースをサポートしています。
アダプタ: 仮想ディレクトリのデータ・ソースごとに適切なドライバをインストールするだけでなく、Oracle Virtual Directoryに接続するディレクトリまたはリレーショナル・データベースごとにLDAPまたはRDBMSアダプタを構成する必要があります。これらのアダプタには、Oracle Virtual Directoryが仮想ディレクトリ・スキーマを使用してネイティブ・データ・ストアのユーザー・プロファイル情報を変換するために使用するマッピング情報が含まれます。詳細は、「データ・ストア・アダプタの作成」を参照してください。
Oracle Access Managerのユーザー・データ、ポリシー・データおよび構成データは、それぞれがLDAPディレクトリ情報ツリー（DIT）のブランチを占有します。Oracle Virtual Directory実装では、各ブランチが特定の場所にある必要があります。表10-3は、これらの要件を示しています。
表10-3 Oracle Access Managerディレクトリのブランチに必要な場所
| ブランチ | 場所 |
|---|---|
|
ポリシー 構成 |
これらのブランチは、Oracle Access Managerレイヤー内の1つ以上のディレクトリ・サーバー上にあることが必要。ホスト・ディレクトリは、Oracle Access Managerのネイティブ・ディレクトリ。 |
|
ユーザー・データ |
すべてのユーザー・データ・ストアは、Oracle Virtual Directoryレイヤー内のOracle Virtual Directoryをホストするコンピュータ上にある最上位ディレクトリの一部であるように見える。 |
図10-10は、Oracle Virtual Directory実装でのポリシー・ブランチおよび構成ブランチの場所を示しています。
図10-10 Oracle Virtual Directory実装でのポリシー・ブランチおよび構成ブランチの場所
この図の内容は、表10-3で説明されています。
Oracle Access Managerが正常に機能するには、スキーマに対してuseridやuserpasswordなどの特定の属性を拡張する必要があります。
仮想ディレクトリでデータ・ストアによって使用されるネイティブ・スキーマまたは表構造とは関係なく、Oracle Access Managerは、Oracle Virtual Directory仮想ディレクトリによって使用されるスキーマのみを参照します。これは、Oracle Virtual Directoryが、様々なデータ・ストアによって使用されるネイティブ・オブジェクト・クラスまたは属性を、仮想ディレクトリによって使用される対応する論理オブジェクト・クラスまたは属性に自動的にマップするためです。
Oracle Virtual Directoryには、業界標準のLDAPディレクトリ・スキーマと非常に類似したデフォルトの仮想ディレクトリ・スキーマが用意されています。企業のニーズに最適な仮想ディレクトリ・スキーマを開発する場合、このスキーマをベースとして使用できます。
スキーマ拡張に必要なファイルは、次の場所にあります。
IdentityServer_install_dir\identity\oblix\tools\\DataAnyWhere\OblixUserSchema\
*.ldif
図10-11は、Oracle Access ManagerとOracle Virtual Directoryの実装に関わる必須のスキーマ拡張タスクとオプションのスキーマ拡張タスクの両方を示しています。
図10-11は、次の手順を示しています。
手順1a: ターゲット・データ・ストア・スキーマに対するOracle Access Managerの補助属性を新しい列としてプライマリ・データベース表に追加します。
手順1: Oracle Access Managerのユーザー・スキーマをターゲット・データ・ストア・スキーマのLDAPディレクトリに追加します。
手順2: ネイティブ・データ・ストアの顧客属性を追加します（オプション）。
手順3: Oracle Access Managerのユーザー・スキーマを仮想ディレクトリ・スキーマに自動または手動で追加します。
表10-4は、仮想ディレクトリの様々なコンポーネントのスキーマ要件を示しています。
表10-4 この実装のコンポーネントのスキーマ要件
| コンポーネント | スキーマ要件 |
|---|---|
|
仮想ディレクトリ |
Oracle Access Managerのユーザー・スキーマを使用した拡張が必要。 また、顧客属性を使用した拡張も必要。 |
|
フェデレーテッド・データ・ソースとしてOracle Virtual Directoryに接続されたLDAPディレクトリ |
Oracle Access Managerのユーザー・スキーマを使用した拡張が必要。 |
|
フェデレーテッド・データ・ソースとしてOracle Virtual Directoryに接続されたデータベース |
プライマリ・データ・ストアとして機能するデータベース表に対する、表の列の追加が必要。各列は、使用する機能を有効化するOracle Access Managerの補助属性を示す。ユーザー・ブランチ・スキーマの各属性によって有効になる特定のOracle Access Managerの機能の詳細は、「Oracle Access Managerの補助属性」を参照。 |
|
分割プロファイル |
プライマリ・データ・ストアのスキーマには、Oracle Access Managerのユーザー・スキーマを使用した拡張が必要。プライマリ・データ・ストアがデータベース表である場合、使用するOracle Access Managerの機能を有効化する補助属性ごとに列の追加が必要。Oracle Access Managerのユーザー・ブランチ・スキーマの各属性によって有効になる特定の機能の詳細は、「Oracle Access Managerの補助属性」を参照。 |
詳細は、次を参照してください。
仮想ディレクトリがOracle Access Managerのすべての機能に接続して使用できるようにするには、適切な属性を使用して仮想ディレクトリを拡張する必要があります。たとえば、Oracle Access Managerでは、Personオブジェクト・クラスおよびGroupオブジェクト・クラスの「フルネーム」、「ログイン」および「パスワード」のセマンティク型に割り当てられた属性が必要です。このユーザー・データとその他の不可欠なユーザー・データがOracle Access Manager対応の各ユーザー・ディレクトリのブランチを占有します。詳細は、アイデンティティ・システムの設定に関する章でオブジェクト・クラスに関する項を参照してください。
Oracle Access Managerスキーマの詳細なリストは、『Oracle Access Managerスキーマ詳細』を参照してください。Oracle Access Managerのユーザー属性を使用してOracle Virtual Directoryスキーマを更新する場合、次の2つの方法を使用できます。
自動: 前述の説明のとおり、アイデンティティ・システムの設定時に「自動構成オブジェクト・クラス」チェック・ボックスを選択すると自動的に更新されます。
手動: 詳細は、「属性の手動構成」に記載されている属性の手動構成に関する項を参照してください。
親仮想ディレクトリのスキーマを拡張するように、仮想ディレクトリに含まれるLDAPディレクトリによって使用されるネイティブ・スキーマも拡張する必要があります。これを行うには、ldapmodify.exeユーティリティを使用します。詳細は、「ディレクトリ・スキーマの拡張」を参照してください。
|
注意: 仮想ディレクトリに含まれる分割プロファイルのプライマリ・データ・ストアにOracle Access Managerの属性を追加することも必要です。詳細は、「表10-4 この実装のコンポーネントのスキーマ要件」を参照してください。 |
仮想ディレクトリに含まれるデータベースについて、使用するOracle Access Managerの機能を有効化する補助属性をシミュレートする表の列を追加する必要があります。これが該当するのは、プライマリ・データ・ストアとして使用されるデータベース表のみです。たとえば、「外出中インジケータ」列を追加し、Oracle Access Managerワークフローのサロゲート機能を有効にします。
|
注意: SQL準拠のデータベースの場合、LDAPオブジェクト・クラスを直接実装する方法はありません。ただし、たとえば、プライマリ・データベース表のすべての行（ユーザー・アカウント）を、仮想ディレクトリによって使用されるPersonオブジェクト・クラスにマップすることにより、オブジェクト・クラスをシミュレートできます。 |
特定の機能を有効化するOracle Access Managerの補助属性のリストは、次を参照してください。
必要に応じて、ネイティブ・データ・ストアの顧客属性を追加することにより、デフォルトのOracle Virtual Directoryスキーマをさらに拡張することもできます。たとえば、デフォルトのOracle Virtual DirectoryのPersonオブジェクト・クラスはUIDですが、アイデンティティ・システムの設定時に、InetOrgPersonを追加してからInetOrgPersonをPersonオブジェクト・クラスとして指定できます。
|
注意: Oracle Virtual DirectoryのためにOracle Access Managerを構成する場合、ユーザーおよびグループのオブジェクト・クラスについて、inetOrgPersonおよびgroupOfUniqueNamesが必要です。 |
Oracle Virtual Directory Manager（VDM、旧称はDME）インタフェースを使用してデフォルトのOracle Virtual Directoryスキーマを変更する方法の詳細は、『Oracle Virtual Directory製品マニュアル』の構成と設定に関する章のスキーマ構成に関する項を参照してください。
Personオブジェクト・クラスの指定の詳細は、「Personオブジェクト・クラスおよびGroupオブジェクト・クラスの指定」のオブジェクト・クラスに関する項を参照してください。
|
注意: 顧客属性が1つのターゲット・データ・ストアに存在するが、他のデータ・ストアには存在しない場合、Oracle Virtual Directoryは、この補助属性をNULLに設定してこれらのその他のデータ・ストアからユーザー・プロファイルを返します。図10-12は、この状況を示しています。 |
図10-12は、単純な仮想ディレクトリにマップされた次の補助属性を示しています。
第1データ・ストア: 基本属性、拡張属性および共通顧客属性にマップされた属性が含まれます。
第2データ・ストア: 第1データ・ストアと同じ属性が含まれますが、一意顧客属性にマップされた属性も含まれます。
したがって、仮想ディレクトリには、次の属性が含まれます。
第1データ・ストアと第2データ・ストアの両方にマップされたOracle Access Managerの基本属性
第1データ・ストアと第2データ・ストアの両方にマップされたOracle Access Managerの拡張属性
第1データ・ストアと第2データ・ストアの両方にマップされた共通補助属性
第1データ・ストアにはないタイプの属性であるために第2データ・ストアのみにマップされた一意顧客属性
ここでは、Oracle Virtual Directoryを使用してOracle Access Managerを実装するときにサポートされる3つのシナリオについて説明します。また、次の各項では、各シナリオにおける制限についても説明します。
Oracle Access ManagerとOracle Virtual Directoryの実装では、1つ以上のベンダーから複数のLDAP v3ディレクトリに接続できます。各ディレクトリには、異なるスキーマ（属性およびオブジェクト・クラス）を使用できます。Oracle Virtual Directoryが実行時にデータを変換するため、Oracle Access Managerは、Oracle Access Managerスキーマが一律に適用された1つのディレクトリとして集約ディレクトリを認識します。
LDAPディレクトリのみが含まれる（RDBMSデータ・ストアは含まれない）Oracle Virtual DirectoryシステムにOracle Access Managerが接続されている場合、アクセス・システムおよびアイデンティティ・システムの機能はすべて使用可能です。ただし、ディレクトリを結合する場合、いくつかの制限に注意する必要があります。
制限:
Oracle Access Managerは、各ユーザー・プロファイルに関連付けられた1つのPersonオブジェクト・クラスと1つのGroupオブジェクト・クラスのみをサポートしています。このため、ネイティブ・ディレクトリの様々な（および場合によっては複数の）Personオブジェクト・クラスとGroupオブジェクト・クラスを、仮想ディレクトリの1つのPersonオブジェクト・クラスと1つのGroupオブジェクト・クラスにマップする必要があります。
構成ディレクトリのネイティブ・ネームスペースは同じでもかまいませんが、これらのネームスペースは仮想ディレクトリ内の異なるネームスペースにマップする必要があります。
仮想ディレクトリによってサポートされるユーザーのログインIDはすべて、含まれるすべてのディレクトリにわたって一意である必要があります。図10-13は、この状況を示しています。
図10-13は、スーパー・ディレクトリに対する2つの同じLDAPディレクトリ・ネームスペースのマッピングを示しています。第1 LDAPディレクトリには、Engineering、MarketingおよびSales属性が含まれます。第2 LDAPディレクトリには、Engineering、MarketingおよびHRのマッピングが含まれます。
スーパー・ディレクトリは、Engineering、Marketing、SalesおよびHR属性にマップされています。このEngineeringとMarketingのマッピングによって追加属性（EastCoastおよびWestCoast用）が追加され、同じスーパー・ディレクトリ・ネームスペースが使用されないようになっています。また、このスーパー・ディレクトリにはSalesおよびHRのマッピングもありますが、この2つのネイティブ・ディレクトリでは同じスーパー・ディレクトリ・ネームスペースが競合していないため、これらのマッピングには追加属性は必要ありません。
構成ディレクトリから仮想ディレクトリの特定の属性にマップされるすべての属性には、共通データ型を使用する必要があります。たとえば、ObOutOfOfficeIndicator属性は、あるデータ・ソースではバイナリ値には設定できませんが、別のデータ・ソースでは日付（ユーザーが戻る日）に設定できます。
ネイティブ・ディレクトリに参照整合性制約がある場合、マネージャやグループ・メンバーなどによる参照は同じネイティブ・ディレクトリからのみ可能です。ネイティブ・ディレクトリに参照整合性制約がなく、このネイティブ・ディレクトリが外部参照もサポートしている場合、別のディレクトリからの参照も可能です。
RDN（相対識別名）はサポートされていません。
Oracle Virtual Directoryによってマップされるすべてのユーザー・プロファイル属性を提供する単一表が含まれるデータベースは、仮想ディレクトリにフェデレートして、Oracle Access Managerから参照することが可能です。複数のデータ表が特定のユーザー・プロファイルに属性を提供している場合、これらの表を結合し、ユーザー属性の完全セットが含まれる仮想データ・ソースを作成するために、4つのオプションが用意されています。
これらのオプションおよびそれぞれの制限の詳細は、「埋込み仮想データ・ソースでのデータベース表の結合の概要」を参照してください。「データベースの接続性に関するヒント」も参照してください。
複数のデータ表が特定のユーザー・プロファイルに属性を提供している場合、これらの表を結合し、ユーザー属性の完全セットが含まれる仮想データ・ソースを作成するために、次の4つのオプションが用意されています。
ネイティブRDBMS結合機能
ネイティブRDBMSビュー機能
Oracle Virtual Directoryの結合ビュー・アダプタ（分割プロファイル）
プリファレンスに基づくカスタム・ジョイナ
図10-14は、サポートされている3つのタイプのうち1つの埋込み仮想データ・ソース内で複数のデータベース表を結合する4つの方式を示しています。
図10-14の4つの方式に関する詳細情報は、次のとおりです。
ネイティブRDBMS結合機能: この方式は、それぞれ独自のマッピング・アダプタを持つプライマリ表およびセカンダリ表によって作成されるRDBMS結合を示しています。Oracle Virtual Directoryのスーパー・ディレクトリ内にはフェデレートできません。追加、変更および削除操作はサポートしていないため、アイデンティティ・システムでの使用には適していません。
ネイティブRDBMSビュー機能: この方式は、それぞれ独自のマッピング・アダプタを持つプライマリ表とセカンダリ表によって作成されるRDBMSビューを示しています。Oracle Virtual Directoryのスーパー・ディレクトリ内にフェデレートできます。RDBMSアプリケーションが追加、変更および削除操作をサポートしている場合、アイデンティティ・システムでの使用に適しています。
Oracle Virtual Directoryの結合ビュー・アダプタ（分割プロファイル）: この方式は、それぞれ独自のマッピング・アダプタを持つプライマリ表およびセカンダリ表によって作成されるOracle Virtual Directoryの結合ビュー・アダプタがある分割プロファイルを示しています。Oracle Virtual Directoryを介してOracle Access Managerに接続することや、Oracle Virtual Directoryスーパー・ディレクトリにフェデレートすることは不可能です。追加、変更または削除操作はサポートしていないため、アイデンティティ・システムでの使用には適していません。
カスタム・ジョイナ: この設計はユーザー・プリファレンスに基づいています。
表10-5は、各方式に関する特定の制限を示しています。
表10-5 仮想ディレクトリ内のデータベース表を結合する方式
| 方式 | 適性と制限 |
|---|---|
|
ホストRDBMSアプリケーションのネイティブ結合機能 生成された結合は、仮想ディレクトリの一部としてフェデレートされる。 |
|
|
ホストRDBMSアプリケーションのネイティブ・ビュー機能 生成されたビューは、仮想ディレクトリの一部としてフェデレートされる。 |
|
|
Oracle Virtual Directoryの結合ビュー・アダプタ方式
|
|
|
カスタム・ジョイナ方式 |
RDBMSアプリケーションのネイティブ結合機能およびビュー機能、または標準の結合ビュー・アダプタによって課される制限を克服するためのカスタム・ジョイナを作成できる。 これにはカスタム・プログラミングが必要。詳細は、『Oracle Virtual Directory製品マニュアル』のジョイナに関する項を参照。 |
各ユーザー・プロファイルの属性を複数のデータ・ソースから取り出す仮想ディレクトリは、分割プロファイルと呼ばれます。これらのデータ・ソースには、LDAPディレクトリとリレーショナル・データベースの任意の組合せを含めることができます。
1つのデータ・ストアがプライマリ・データ・ソースとして機能します。このデータ・ストアのスキーマは、Oracle Access Manager固有のユーザー・データを使用して拡張する必要があります。詳細は、「スキーマ拡張の概要」を参照してください。
その他のデータ・ストアはすべてセカンダリ・データ・ソースです。これらのセカンダリ・データ・ストアに対して、アイデンティティ・システム機能の一部はサポートされていません。詳細は、「結合ビュー・アダプタの要件と制限」を参照してください。セカンダリ・データ・ストアに対してOracle Access Managerのユーザー・スキーマを拡張する必要はありません。
分割プロファイルのデータ・ソースは、Oracle Virtual Directoryの標準の結合ビュー・ツール（推奨方式）またはカスタム・ジョイナを使用して結合できます。カスタム・ジョイナの作成の詳細は、『Oracle Virtual Directory製品マニュアル』を参照してください。
結合ビュー・アダプタは、プライマリ・データ・ストアまたはセカンダリ・データ・ストア内の属性に対するすべてのアクセス・システム操作をサポートしています。これには、認証、認可、監査およびシングル・サインオンが含まれます。
|
注意: アイデンティティ・システム操作もサポートされていますが、次の制限があります。 |
制限
分割ディレクトリのユーザーのログインID属性は、プライマリ・データ・ストア内にある必要があります。また、ユーザーのログイン・パスワードおよびユーザーのフルネーム属性も、プライマリ・データ・ストア内にある必要があります。
Oracle Access Managerのユーザー・スキーマは、プライマリ・データ・ストア内にある必要があります。
ベース・レベル検索は、プライマリ・データ・ストアおよびセカンダリ・データ・ストアの両方に対してサポートされます。
サブツリー検索は、プライマリ・データ・ストアに対してのみサポートされます。暗黙的に、次の制限が適用されます。
セカンダリ・データ・ストア内の属性は、検索可能として構成できません。
セカンダリ・データ・ストア内の属性は、サブツリー検索が関わるフィルタ操作の対象として構成できません。これには次が含まれます。
ドメイン・フィルタ
動的グループ・フィルタ
グループ・サブスクリプション・フィルタ
クエリー・ビルダー・フィルタ
属性が存在する特定のデータ・ストアとは関係なく、すべての属性に対して変更操作がサポートされています。
ユーザー、グループおよびその他のオブジェクトは、プライマリ・データ・ストア内でのみ作成できます。
プライマリ・データ・ストア内のユーザー、グループおよびその他のオブジェクトのみ削除できます。（Oracle Access Managerアプリケーションは、セカンダリ・データ・ストア内のオブジェクトは削除できません。これは、ターゲットRDBMSアプリケーションまたはLDAPディレクトリを使用してのみ実行できますが、リアルタイム環境では同期問題が発生する可能性があります。）
特定の属性は、1つのデータ・ストアからのみ構成できます。結合値はサポートされていません。
Oracle Access Managerは、仮想ディレクトリに対して他のLDAPディレクトリの場合と同様にアクセスします。このため、サポートされているほとんどのOracle Access Manager構成はOracle Virtual Directoryと円滑に統合できます。次の項では、Oracle Access ManagerとOracle Virtual Directoryの実装の様々な側面におけるサポートおよび要件の詳細を説明します。
Oracle Access Manager: Oracle Access Managerの構成およびポリシー・データが含まれるLDAPディレクトリのブランチは、Oracle Access Managerの1つ以上のネイティブ・ディレクトリ・サーバー上に存在する必要があります。つまり、構成およびポリシー・ブランチは、Oracle Access Managerから参照可能なすべてのユーザー・データが含まれる仮想ディレクトリに存在することはできません。
前述の説明のとおり、構成、ポリシーおよびユーザー・データの場所は、アイデンティティ・サーバー、ポリシー・マネージャおよびアクセス・サーバーのインストールおよび設定時に指定します。
Oracle Virtual Directory: Oracle Virtual Directoryをインストールするホスト・コンピュータの操作に関する最新のサポートの詳細は、次のサイトにあるOracle Technology Network（OTN）を参照してください。
http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls
2007年には、アメリカ合衆国内で夏時間（DST）の実施日程が変更されます。ホスト・コンピュータのオペレーティング・システムが新しいDSTへの移行を正しく処理すれば、Oracle Virtual Directoryへの影響はありません。オペレーティング・システムがDST 2007に対応していれば、Oracle Virtual Directoryも対応しています。詳細は、My Oracle Support（旧称MetaLink）に記載されている次の項目を参照してください。
Note 357056.1: 夏時間（DST）規則の変更によるOracleデータベースへの影響
Note 359145.1: 2007年のアメリカ合衆国の夏時間変更によるOracleデータベースへの影響
Note 360803.1: AUタイムゾーンのデータベースおよびFusion Middlewareの推奨事項
Note 391354.1: 2007年のアメリカ合衆国の夏時間（DST）変更によるOracle Internet DirectoryまたはOracle Application Serverへの影響
Note 397281.1: データベースおよびFusion Middlewareに関する2007年のアメリカ合衆国の夏時間（DST）準拠
Note 401010.1: 西オーストラリアの夏時間変更に関するデータベースおよびFusion Middlewareの推奨事項
My Oracle Support（旧称MetaLink）Webサイトでのナレッジ・ベース項目の検索手順
https://metalink.oracle.comにあるMy Oracle Supportに移動します。
指示に従ってログインします。
「ナレッジ」タブをクリックします。
クイック検索リストから「ナレッジ・ベース」を選択し、項目番号を入力して「実行」ボタンをクリックします。
表示する項目の名前を結果リストでクリックします。
オペレーティング・システム: Oracle Virtual Directoryは、サポートされるオペレーティング・システムが動作するホスト・コンピュータ上にインストールされたOracle Access Managerコンポーネントを使用して実装できます。
仮想ディレクトリによってサポートされているLDAPディレクトリおよびRDBMSデータベースは、Oracle Virtual Directoryによってサポートされているホスト・プラットフォームにインストールできます。
Javaランタイム環境: Oracle Virtual Directoryをインストールするホスト・コンピュータには、Javaランタイム環境がインストールされている必要があります。
Oracle Access ManagerとOracle Virtual Directoryの実装は、JRE v1.4を使用してテストされています。
JNDIドライバ: サポートされているOracle Virtual Directoryインストール・パッケージに同梱されているJNDIドライバを使用します。
JDBCドライバ: Oracle Virtual Directoryをホストするコンピュータ上で、仮想ディレクトリに接続するRDBMSアプリケーションに適したバージョンのJDBCドライバをインストールする必要があります。適切なドライバはRDBMSアプリケーションのベンダーから入手できます。Oracle Virtual Directoryデータベース・アダプタは、JDBCドライバを備えたデータベースをサポートしています。
仮想ディレクトリに複数のベンダーのデータベースが含まれる場合、使用されているベンダーごとにJDBCドライバをインストールする必要があります。詳細は、『Oracle Virtual Directory製品マニュアル』を参照してください。
データセット: Oracle Access ManagerとOracle Virtual Directoryの実装には、UTF-8キャラクタ・セットが使用されます。Oracle Virtual Directoryはローカライゼーションに対応していますが、明示的にサポートされているのは英語のみです。
リレーショナル・データベース: 通常、Oracle Access Managerは、Oracle Virtual DirectoryによってサポートされているRDBMSデータベースが含まれる任意の仮想ディレクトリに接続できます。詳細は、Oracle Access ManagerとOracle Virtual Directoryの実装についてサポートされているRDBMSアプリケーションを示す「図10-2 フェデレーテッドRDBMSアプリケーションが含まれるOracle Virtual Directory実装」を参照してください。「データベースの接続性に関するヒント」も参照してください。
ディレクトリ・サーバー: 通常、Oracle Access Managerは、Oracle Virtual DirectoryによってサポートされているLDAPディレクトリ・サーバーに接続できます。「図10-1 フェデレーテッドLDAPディレクトリがあるOracle Virtual Directory実装」は、Oracle Access ManagerとOracle Virtual Directoryの実装用としてサポートされているLDAPディレクトリ・サーバーを示しています。
キャッシング: Oracle Virtual Directoryは、キャッシングは明示的にはサポートしていません。
Oracle Access ManagerとOracle Virtual Directoryの実装の要件およびサポートの詳細は、次を参照してください。
オープン接続またはSSL接続は、Oracle Access ManagerとOracle Virtual Directory間、およびOracle Virtual Directoryとネイティブ・データ・ストア間でサポートされています。
Active Directoryの場合、ADSIはサポートされていません。Active Directory内でパスワードを変更する場合、「SSL」を使用する必要があります。そうでない場合は、「オープン」モードを使用できます。
|
注意: Active DirectoryをOracle Virtual Directoryに接続する場合、最良のパフォーマンスを実現するには、セキュリティ接続モードとして「Password Only SSL」を指定します。このシナリオの場合、Oracle Virtual DirectoryとActive Directoryの間にオープン接続を確立する必要もあります。 |
図10-15は、Oracle Access ManagerとOracle Virtual Directoryの実装内で接続に使用されるプロトコルを示しています。
図10-15 単純なOracle Access ManagerとOracle Virtual Directoryの実装におけるプロトコルのサポート
この図は、図10-8で詳細に説明した3つのレイヤーにおけるプロトコルのサポートを示しています。各レイヤーの説明は、次のとおりです。
Oracle Access Managerレイヤー: アイデンティティ・システムを示しています。
VDSレイヤー: Oracle Access Managerレイヤーのアイデンティティ・システムにアクセスするOracle Virtual Directoryレイヤーを示しています。また、ターゲット・データ・ストア・レイヤーのActive DirectoryおよびSunにもアクセスしています。
ターゲット・データ・ストア・レイヤー: Active DirectoryおよびSunを示しています。Active Directoryは、LDAP over SSL（パスワードのみ）およびLDAP over Openを介してOracle Virtual Directoryレイヤーにアクセスしています。Sunは、LDAP over SSLまたはLDAP over Openを介してOracle Virtual Directoryにアクセスしています。Active DirectoryはASDLを使用できません。Active Directoryでパスワードを変更する場合、「SSL」モードを使用する必要があります。そうでない場合は、「オープン」モードを使用できます。
Oracle Virtual Directoryは、次の認証方式をサポートしています。
資格証明の受渡し認証
単純プロキシ
Oracle Access ManagerとOracle Virtual Directoryの実装に資格証明の受渡し認証を使用する場合、「passCredentials」を「常時」（または「バインドのみ」）に設定し、Oracle Access Managerによって提供されているユーザーの識別名とパスワードをOracle Virtual Directoryがプロキシ設定対象LDAPディレクトリに渡すようにします。
背景的な詳細は、『Oracle Virtual Directory製品マニュアル』の構成と設定に関する章のディレクトリ・ネームスペースと属性マッピングに関する項を参照してください。
Oracle Access ManagerとOracle Virtual Directoryの両方のアクセス制御がオンになっており、Oracle Access ManagerとOracle Virtual Directory間の接続についてデフォルト設定が有効化されていることを確認します。背景的な詳細は、『Oracle Virtual Directory製品マニュアル』のセキュリティとアクセス制御に関する章を参照してください。
Oracle Virtual Directoryとターゲット・データ・ストア間の接続については、サポートされているターゲット・データ・ストアごとにアクセス制御をオンにします。（Oracle Virtual Directoryは、LDAPクライアントであるため、ターゲット・ディレクトリ・サーバーごとに固有のアクセス制御実装を使用する必要があります。）詳細は、『Oracle Virtual Directory製品マニュアル』の構成と設定に関する章のアクセス制御とLDAPアダプタに関する項を参照してください。
Oracle Access ManagerとOracle Virtual Directoryの実装では、Oracle Access Manager、Oracle Virtual Directory、ディレクトリ・サーバーおよびRDBMSアプリケーションの既存のフェイルオーバー機能を使用してフェイルオーバーのサポートが実装されます。フェイルオーバーは、次の3つのレベルで実装できます。
Oracle Access Managerのフェイルオーバー
Oracle Virtual Directoryのターゲット・ソースのフェイルオーバー
ターゲット・データ・ストアのフェイルオーバー
Oracle Access Managerのフェイルオーバー: アイデンティティ・サーバーまたはアクセス・サーバーは、1つ以上のプライマリ仮想ディレクトリ・インスタンス、および1つ以上のセカンダリOracle Virtual Directoryインスタンスにアクセスできます。
『Oracle Access Manager IDおよび共通管理ガイド』のアイデンティティ・システムの管理と構成に関する章のLDAPサーバー・プロファイルへのデータベース・インスタンスの追加に関する項を参照してください。
Oracle Access Managerでのフェイルオーバーの構成の詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
『Oracle Virtual Directory製品マニュアル』の仮想ディレクトリの計画に関する章のフォルト・トレラントのデプロイに関する項を参照してください。
Oracle Virtual Directoryのターゲット・ソースのフェイルオーバー: Oracle Virtual Directoryでは、仮想ディレクトリとターゲット・データ・ストア間でフェイルオーバー保護を実装できます。詳細は、『Oracle Virtual Directory製品マニュアル』の仮想ディレクトリの計画に関する章のフォルト・トレラントのデプロイに関する項を参照してください。
ターゲット・データ・ストアのフェイルオーバー: 多くの場合、RDBMSアプリケーションおよびLDAPディレクトリ・サーバーは、ターゲット・データ・ストア・レベルでのクラスタリングという形式でフェイルオーバーをサポートしています。通常、この機能を実装するメカニズムは自動的に動作し、Oracle Virtual DirectoryやOracle Access Managerからは認識できません。詳細は、RDBMSアプリケーションまたはLDAPディレクトリ・サーバーに関するドキュメントを参照してください。
|
注意: この章では、環境に応じてフェイルオーバーを構成するための特定の手順は示しません。フェイルオーバーは、製品のドキュメントに従って通常どおりに設定できます。 |
図10-16は、Oracle Access ManagerとOracle Virtual Directoryの実装内で潜在的に使用可能なフェイルオーバーのタイプを示しています。
図10-16 Oracle Access ManagerとOracle Virtual Directoryの実装におけるフェイルオーバーのオプション
この項では、実装プロセスについて説明します。
Oracle Access Managerをまだインストールしていない場合、Oracle Virtual Directoryとの実装を完了するために説明されている作業を行う必要があります。
タスクの概要: Oracle Access Managerのインストール時のOracle Virtual Directoryの実装
Oracle Virtual Directory（Data Anywhere）を使用してOracle Access Managerを実装するための環境の準備には、次の作業が含まれます。
タスクの概要: 環境の準備
実装を開始する前に、情報を収集し、Oracle Access ManagerとOracle Virtual Directoryの実装の設計方針を決定します。
必要に応じて、背景的な調査を実行し、次の各質問について検討して回答します。
この実装の要素の識別の手順
Oracle Virtual Directoryを介してアクセスするデータ・ストアを確認します。
仮想ディレクトリ内ではLDAPディレクトリおよびRDBMSデータベースをフェデレートできます。また、分割プロファイル、ネイティブRDBMS結合およびネイティブRDBMSビューなどの埋込み仮想データ・ソースも作成およびフェデレートできます。
ターゲット・データ・ソースとしてのLDAPディレクトリの選定: Oracle Access Managerには、Oracle Access ManagerがOracle Virtual Directoryの実装用としてサポートしているLDAPディレクトリ・サーバーごとにアダプタ・テンプレートおよびスキーマ・マッピング・テンプレートの両方が用意されているため、LDAPディレクトリの組込みは比較的簡単です。「DN変換ツールキットの概要」を参照してください。
唯一の重要な制限は、スーパー・ディレクトリでは2つのディレクトリが同じネームスペースを占有できないことです。ただし、ネイティブ・ディレクトリによって使用されるネームスペースをスーパー・ディレクトリ内の一意のネームスペースにマップすることにより、このような競合を回避できます。詳細は、「集約ネームスペース」を参照してください。
ターゲット・データ・ソースとしてのRDBMSデータベースの選定: RDBMSデータベースの場合、Oracle Access Managerが動作するために不可欠なすべての情報が単一表内に存在するかどうかを最初に確認する必要があります。これには、次の属性にマップされるデータベース列が含まれます。
UID（ユーザー・ログインID）
ユーザー・パスワード
フルネーム
Personオブジェクト・クラス。これは通常、重要なフィールドがある表の名前によって暗黙的に示されます。たとえば、データベースの従業員表のユーザー・アカウントはすべて、仮想ディレクトリのinetorgperson Personオブジェクト・クラスにマップできます。コンサルタントなどの別の表がある場合、そのユーザー・アカウントもすべてinetorgpersonにマップしてから、ネイティブRDBMS結合またはビュー機能を使用してこれらのユーザー・アカウントを連結できます。守るべき重要な原則は、仮想ディレクトリによって指定される1つのPersonオブジェクト・クラスにすべてのユーザー・アカウントを関連付ける必要があるということです。
使用する特定の機能を有効化するために必要なOracle Access Managerのユーザー・ブランチ属性。たとえば、OOO（Out of Office: 外出中）というラベルの列を従業員表に追加することにより、仮想ディレクトリについてワークフローを実行できるようになります。
重要な情報がすべて単一表内にある場合、データベースを仮想ディレクトリの一部としてフェデレートできます。一部の重要情報がデータベース内にない場合、またはこの情報が複数の表に分散している場合、このデータベースは仮想ディレクトリに含めることに適していない場合があります。または、使用可能な3つの方式の1つを使用し、データベースを埋込み仮想データ・ソースに変換してから仮想ディレクトリ内にフェデレートする必要がある場合があります。
Oracle Virtual Directory RDBMSアプリケーション ネイティブLDAPディレクトリ・サーバー
Oracle Access Managerから参照可能な仮想ディレクトリ情報の項目を確認します。
Oracle Access Managerが仮想ディレクトリと対話できることを確認するには、手順1に記載されている重要項目がOracle Access Managerから参照できるようにする必要があります。また、Oracle Access Managerから参照可能な顧客属性も確認する必要があります。たとえば、従業員の携帯電話番号または誕生日を仮想ディレクトリに追加することにより、これらの属性を参照可能にできます。
オブジェクト・クラスと属性をマップするために最適な方式を確認します。
これは、ターゲット・データ・ストアによって使用されるネイティブ・スキーマによって異なります。Oracle Virtual Directoryを介してOracle Access Managerから参照する仮想スキーマは自由に作成できますが、次の点に注意する必要があります。
2つの異なるターゲット・データ・ストアの情報がスーパー・ディレクトリ内の同じネームスペースを占有することはできません。
仮想ディレクトリに埋込み仮想データ・ストアが含まれる場合は通常、セカンダリ・データ・ストアの情報を変更できないため、ユーザー・アカウントを作成、削除または変更するワークフローは使用しないようにする必要があります。
埋込み仮想ディレクトリ（分割プロファイル、RDBMS結合およびRDBMSビュー）のセカンダリ・データ・ストアをフィルタまたはサブ検索に含めることはできません。つまり、分割プロファイル、RDBMS結合およびRDBMSビューなどの埋込み仮想データ・ストアは、アクセス・システム操作（認証および認可）には適していますが、多くの場合、セカンダリ・データ・ストアのデータに対しては追加、削除および変更などの主要機能を使用できないため、通常、これらのデータ・ストアはID管理操作には適していません。
Oracle Access ManagerとOracle Virtual Directoryの実装では、複数の値を持つ属性と、ターゲット・データ・ストアとして使用されるデータベースを同時にはサポートできません。仮想ディレクトリにLDAPディレクトリのみが含まれる場合は、多値属性を使用できます。
|
注意: データベースとともに多値属性を使用する必要がある場合は、「Oracle Access ManagerとOracle Virtual Directoryの実装のテンプレート」および「複数値属性の問題」を参照してください。 |
仮想ディレクトリの情報ごとにOracle Access Managerが実行する操作を確認します。
Oracle Access Managerの特定の機能（ワークフローでのサロゲートなど）を使用する場合、埋込み仮想データ・ストアのプライマリ・データベース表に列を追加する必要があります。特定のUser ManagerおよびGroup Manager機能と、ターゲット・データ・ストアとして機能するデータベースのプライマリ表に追加する必要があるOracle Access Managerの補助ユーザー属性の相関関係を示すリストは、「ターゲット・データベース表への属性の追加の概要」および「Oracle Access Managerの補助属性」を参照してください。
ポリシー管理とID管理の観点から、仮想ディレクトリに最適なDIT階層を確認します。
非結合検索ベースと統合検索ベースのどちらかを選択できます。詳細は、「検索ベースのオプションの概要」を参照してください。
スーパー・ディレクトリ・オプションを選択した場合、組織のニーズにあわせてネームスペース集約とスキーマ・マッピングを最適化できます。たとえば、企業が合併された場合、2つの会社のエンジニアリング・ディレクトリを集約できるため、新しい会社のすべてのエンジニアについて構成が必要なアクセス・ポリシーは1セットのみです。このようなシナリオを処理したネームスペース・マッピングの簡単な例は、「集約ネームスペース」を参照してください。
コンポーネントをホストするコンピュータを確認し、次のインストール先を確認します。
Oracle Access Manager
Oracle Virtual Directory
RDBMSアプリケーション
ネイティブLDAPディレクトリ・サーバー
次の作業に進みます。
Oracle Virtual Directoryに統合するネイティブ・ディレクトリ・サーバーをインストールおよび構成する必要があります。この作業はここで実行できます。
|
注意: 後で実行する2つ目の要件として、Oracle Access Manager関連のユーザーおよびグループ情報を使用して各バックエンド・ディレクトリ・サーバーのネイティブ・スキーマを拡張する必要があります。これにより、Oracle Virtual Directoryおよびネイティブ・スキーマに同じOracle Access Manager属性が含まれます。 |
各ディレクトリ・サーバーの準備の手順
「実装要件」を確認します。
ベンダーの指示に従ってバックエンド・ディレクトリ・サーバーをインストールします。
後で、Oracle Access Manager関連の属性を使用してネイティブ・スキーマを拡張します。
続行する前に、ディレクトリに含める各リレーショナル・データベースの準備を開始する必要があります。この手順は、RDBMS固有のアダプタを作成するための前提条件です。
実装用の各リレーショナル・データベースの準備の手順
ベンダーの指示に従ってRDBMSをインストールおよび構成します。
仮想ディレクトリによって使用されるOracle Access Managerスキーマの重要な属性にマップする必要があるフィールドがすべてデータベースの単一表に含まれていることを確認します。これは次のとおりです。
UID
ユーザー・パスワード
フルネーム
次の各項目を考慮してください。
データベースに重要なフィールドがすべて含まれていない場合、このデータベースは仮想ディレクトリに含めることに適さない可能性があります。
重要なフィールドがすべて同じ表内にない場合、この表を仮想ディレクトリに含めることはできません（セカンダリ表に存在する重要なフィールドは検索できないためです）。オプションの顧客フィールドはセカンダリ表に格納できます。
重要なフィールドがすべて同じ表内にある場合、次のいずれかの方式を使用して埋込み仮想データ・ストアを作成する必要がある場合があります。
結合ビュー・アダプタ
RDBMSアプリケーションのネイティブ・ビュー機能
RDBMSアプリケーションの結合機能
|
注意: 前述の複数表のデータベースを組み込むための3つの方式では、特定のアイデンティティ・システム機能が必ず制限されます。 |
RDBMSアプリケーションのベンダーのWebサイトから必要なドライバ・ライブラリをダウンロードします。
たとえば、Oracleの場合、Oracle JDBCシン・ドライバ（ojdbc14.jar以上）をダウンロードする必要があります。
ベンダーの指示に従ってドライバをインストールします。
「Oracle Virtual DirectoryとVirtual Directory Managerのインストールおよび構成」にスキップします。
後で、Oracle Virtual Directoryをホストするコンピュータ上のターゲット・データベースに対してJDBCドライバをデプロイするよう指示されます。
「データベースの接続性に関するヒント」も参照してください。
実装構成を選択し、データ・ソースを準備した後、実装に必要なOracle Access ManagerとOracle Virtual Directoryソフトウェアの両方をインストールする必要があります。次のタスクの概要は、実行する必要がある手順を示しています。
タスクの概要: Oracle Virtual DirectoryとVirtual Directory Managerのインストールおよび構成
RDBMS: RDBMS用のJDBCドライバ・ライブラリのデプロイ
Oracle Virtual Directoryを通常どおりインストールします。Oracle Access Managerとの実装を容易にするために必要な特定の手段はありません。
Oracle Virtual Directoryのインストールの手順
『Oracle Virtual Directory and Virtual Directory Manager Installation Guide』の指示に従ってOracle Virtual Directoryをインストールおよび設定します。
Oracle Virtual Directoryのドキュメントに記載されているデフォルト設定を使用します。
最初のアイデンティティ・サーバーをインストールするときに使用するOracle Virtual Directoryインストールに関する情報を記録します。これには次が含まれます。
Host Name: Oracle Virtual DirectoryをホストしているコンピュータのDNSホスト名。
Port Number: Oracle Virtual DirectoryのLDAPライセンス・ポート。
Bind DN for the user data directory server: 仮想ツリーの任意の場所にあるOracle Virtual Directoryの仮想DN。
Password: ユーザー・データのバインドDNのパスワード。
Oracle Virtual Directoryのドキュメントの説明に従ってOracle Virtual Directoryを構成します。
|
注意: Oracle Virtual DirectoryとOracle Access Manager間でSSL接続を構成する場合は、「Oracle Virtual DirectoryのSSLリスナーの構成（オプション）」を参照してください。 |
Virtual Directory Managerを通常どおりインストールします。Oracle Access Managerとの実装を容易にするために必要な特定の手段はありません。
Virtual Directory Managerのインストールの手順
『Oracle Virtual Directory and Virtual Directory Manager Installation Guide』の指示に従います。
Oracle Virtual Directoryのドキュメントに記載されているデフォルト設定を使用します。
Oracle Virtual Directoryのドキュメントに説明に従ってVirtual Directory Managerを構成します。
「プロジェクト領域およびサーバーの作成」に進みます。
Virtual Directory Managerを使用して通常どおりにプロジェクト領域およびサーバーを作成します。ここでは一部のサンプルの手順を示しますが、これらは完全なチュートリアルではありません。
詳細は、Oracle Virtual Directoryのドキュメントを参照してください。
プロジェクト領域およびサーバーの作成の手順
「スタート」から「VDM」を選択します。
サーバー・ナビゲータ・ウィンドウの下にあるメニューから、「ディレクトリ管理プロジェクト」を選択します。
一意のプロジェクト名を指定します。
プロジェクト名を右クリックしてから、「新規」→「Server」を選択します。
一意のサーバー名を入力します。
「終了」をクリックします。
Oracle Virtual Directory 10.1.4以降では、Oracle Virtual Directory Manager内で、すぐに使用できるOracle Access Managerのテンプレートおよびマッピングのサンプルが提供されます。Oracle Virtual Directoryのリリースに応じて、次の作業を実行します。
Oracle Virtual Directory 10.1.4以降を使用している場合は、この項をスキップして、それぞれの環境に応じて後続の項をすべて実行します。
10.1.4より前のOracle Virtual Directoryのリリースを使用している場合、もしくはOracle Access Managerディストリビューションに含まれるアダプタおよびマッピングのサンプル・テンプレートを使用する場合は、引き続き、この項に含まれる情報および手順に従います。
Oracle Access Managerディストリビューションは、各データ・ストアに固有のサンプル・テンプレートと、ユーザー定義のスキーマに固有のサンプル・テンプレートの2種類のサンプル・テンプレートを提供しています。
サンプル・アダプタ・テンプレート: ネイティブ・データ・ストアをOracle Virtual Directoryに接続する個々のアダプタの基準として使用可能なベンダー固有のアダプタ・ファイルのサンプル・テンプレート。オラクル社は、Oracle Virtual Directoryのインストールでアダプタ・テンプレートのサンプルを提供しています。これらのテンプレートは、Oracle Virtual Directory内のアダプタ・テンプレート・リストで自動的に使用可能になります。ただし、必要に応じて独自のテンプレートを最初から作成することもできます。
オラクル社提供のサンプル・アダプタ・テンプレート・ファイルは、次の場所に格納されています。
IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\plugins\
OracleAccessManagerOVIDTEmplates
\adapter_templates
サンプル・マッピング・テンプレート: Oracle Virtual Directoryが、ネイティブ・データ・ストアによって使用されるスキーマ（またはデータベース・フィールド）を、Oracle Access Managerから参照する集約仮想ディレクトリによって使用される論理スキーマに変換できるようにするためのサンプル・マッピング・ファイル。オラクル社提供のサンプル・マッピング・テンプレートは、次の場所に格納されています。
IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\plugins\
\OracleAccessManagerOVIDTEmplates\mapping_templates
|
注意: この時点では、サンプル・テンプレートを取得および更新するのみです。後で、これらのテンプレートを使用して各コネクタを構成し、スキーマとネームスペースのマッピングを行います。詳細は、「アダプタのマッピング・ファイルの作成」および「データ・ストア・アダプタの作成」を参照してください。 |
Virtual Directory Managerへのサンプル・テンプレートのコピーの手順
必要に応じて、Oracle Access Managerで提供されるテンプレートを次のように入手します。
DNConversionToolkitからファイルを取得します。
配布されたzipファイル（たとえばCOREidFeatures_10.1.4.bin.dist.zip）をOracle Virtual Directory Managerディレクトリに解凍します。次に例を示します。
VDM_install_dir\ for example C:\Oracle\OViD Manager
Oracle Virtual Directory Managerを再起動します。
環境に応じて、次のいずれかの作業に進みます。
この手順を実行するのは、実装にRDBMSが含まれる場合のみです。
JDBCドライバ・ライブラリのダウンロードおよびインストールと前述の手順が完了した後、次の手順を実行して各ライブラリをデプロイする必要があります。たとえば、Oracleの場合、Oracle JDBCシン・ドライバ（ojdbc14.jar以上）をデプロイする必要があります。
また、ここで説明する内容は作業方法の概要を示すものです。詳細は、Oracle Virtual Directoryのドキュメントを参照してください。
JDBCドライバ・ライブラリのデプロイの手順
「実装用のリレーショナル・データベースの準備」の作業を実行します。
通常どおりVirtual Directory Managerを起動し、サーバー・ナビゲータ・ウィンドウに移動します。
Oracle Virtual Directoryを右クリックし、メニューから「サーバー・ライブラリの管理」を選択します。
ファイル・メニューを選択します。
ファイル・メニューから「新規」→「デプロイ」を選択します。
JDBCドライバ・ファイルは、JDBC_Driver_install_dir/lib（C:\Program Files\JDBCなど）に格納されています。
環境に応じてライブラリを選択します。
msbase.jar
mssqlserver.jar
msutil.jar
通常どおりデプロイします。
次の手順が必要なのは、Oracle Access ManagerとOracle Virtual Directory間のSSL接続を設定する場合のみです。オープン接続を使用する場合は、この項はスキップしてください。
Oracle Virtual DirectoryのSSLリスナーの構成の手順
次のように、秘密鍵を生成します。
サーバーを右クリックし、「Server Managerサーバー・キー」を選択します。
「キーの生成」をクリックします。
鍵情報を入力します。
使用する「共通名」は、後でOracle Access Managerで使用するホスト名と正確に同じものである必要があります。
次のように、証明書リクエストを生成します。
キー/証明書ウィンドウで生成した鍵を選択します。
「リクエスト証明書」をクリックします。
次のように、証明書リクエストに署名します。
http://computer/certsrvを使用してMicrosoft Certificateサービスを起動します。
「証明書の要求」リンクをクリックします。
「証明書の要求の詳細設定」リンクをクリックします。
「Base 64 エンコード CMC または PKCS #10 ファイルを使用して証明書の要求を送信するか....」リンクをクリックします。
エディタで、手順2で生成した証明書リクエスト・ファイルを開きます。
テキストをコピーして証明書サービスのBase64エンコード・ウィンドウに貼り付けます。
「証明書テンプレート」で「Webサーバー」を選択し、「送信」を選択します。
CA証明書をBase64エンコード形式でダウンロードします。
次のように、署名した証明書をOracle Virtual Directoryにインポートします。
Virtual Directory Managerのキー/証明書ウィンドウで、「インポート」をクリックします。
手順3で取得した証明書ファイルを選択します。
手順1の鍵に指定されている別名とまったく同じ別名を指定します。
終了すると、鍵エントリの発行者がCAに対して更新されます。
次のように、SSLを使用してLDAPリスナーを構成します。
Virtual Directory Managerの「Server Navigation」ペインで、「リスナー」をクリックし、「新規LDAPリスナー」を選択します。
ポートを指定します。
「サーバー・キーの別名」で、手順4で作成した鍵エントリを選択します。
サーバーに保存します。
次の条件に応じてOracle Access Managerに証明書をインストールします。
アイデンティティ・サーバーがインストールされていない場合: アイデンティティ・サーバーのインストール時に証明書を自動的にインストールできます。この場合、「最初のアイデンティティ・サーバーのインストール」にスキップしてください。
アイデンティティ・サーバーがインストールされている場合: 次の手順を実行し、証明書を作成およびインポートします。
必要に応じて、cert8.dbを作成します。
IdentityServer_install_dir\identity\oblix\tools\certutilに移動します。
次のコマンドを実行します。
certutil -d IdentityServer_install_dir\identity\oblix\config -N -f
次のコマンドを使用してルートCAをアイデンティティ・サーバーにインポートします。
certutil -d IdentityServer_install_dir\identity\oblix\config -A -n ldap -a -t "C,," -i root_ca_file
|
注意: certutilコマンドでは、-t（信頼できる引数）フラグの後に、証明書に割り当てられる信頼属性を二重引用符で囲んで記述する必要があります。 |
次のように、アイデンティティ・サーバーを再構成します。
「アイデンティティ・システム・コンソール」から、「システム構成」→「ディレクトリ・オプション」を選択します。
『Oracle Access Manager IDおよび共通管理ガイド』で説明されているように、ユーザー・プロファイルおよびDBインスタンスを検索します。
SSLをマークしてから、Oracle Virtual Directoryのセキュア・ポートを入力します。
アイデンティティ・サーバーを再起動します。
SSLを使用するすべてのインスタンスについてこの作業を繰り返します。
『Oracle Access Manager IDおよび共通管理ガイド』で説明されているように、アイデンティティ・システムの設定を手動で再実行します。
Oracle Virtual Directoryを使用した実装を成功させるには、Oracle Access Managerのインストールを段階的に実行する必要があります。1つ目のフェーズでは、最初のアイデンティティ・サーバーのみをインストールします。このインストールには、Oracle Virtual Directoryと統合するディレクトリ・サーバーのネイティブ・スキーマを拡張するために必要なldifファイルが用意されています。
Oracle Virtual Directory用のアイデンティティ・サーバーのインストール時には、次を指定する必要があります。
User Data Directory Server: ユーザー・データ・ディレクトリ・サーバーを指定するよう求められた場合、Data Anywhereを選択します。
Configuration and Policy Data Directory Server: 構成およびポリシー・データの場所を指定するよう求められた場合、ネイティブ・ディレクトリ・サーバーを指定します。構成およびポリシー・ブランチは、Oracle Virtual Directoryインストールと同じホスト・コンピュータ上に存在することはできません。
次の手順が終了すると、Oracle Virtual Directoryと統合するネイティブ・ディレクトリ・サーバーのスキーマを拡張できます。
|
注意: 複数のユーザー・ディレクトリ・サーバー・プロファイルがある場合、ユーザー・エントリの各識別名が一意であることを確認してください。一意でない場合、認証時に混乱を招くことがあります。 |
最初のアイデンティティ・サーバーのインストールの手順
第I部「インストールの計画と前提条件」で、インストールの前提条件、要件、オプション、およびアイデンティティ・サーバーのインストールに関する考慮点を確認します。
第4章「アイデンティティ・サーバーのインストール」で説明されているように、最初のアイデンティティ・サーバーのインストールを開始し、ディレクトリ・サーバーの詳細の定義に進みます。
Oracle Access Managerの構成データは個別に格納する必要があります。後で、ユーザー・データ・ディレクトリ・サーバーと構成データ・ディレクトリ・サーバーの両方に関する詳細を指定するよう求められます。
データの格納先を指定するよう求められた場合、構成データは個別に格納するよう指定します。
個別に格納する構成データ
最初のアイデンティティ・サーバーのインストール時にスキーマを自動的に格納することをお薦めします。スキーマは1回のみ更新します。「はい」を選択すると、ディレクトリ・サーバー・タイプおよび仕様について質問されます。
スキーマの更新について指定を求められた場合、ユーザーおよび構成データの個別格納に対してスキーマ更新オプションの「Automatic」を選択します。
ユーザー・データ・ディレクトリ・サーバーの詳細の指定を求められた場合、この実装について次を指定します。
User Data Directory Server: Data Anywhere。
ユーザー・データ・ディレクトリ・サーバーの詳細:
Host Name: Oracle Virtual DirectoryをホストしているコンピュータのDNSホスト名。
Port number: ディレクトリ・サーバーがリスニングするポート: Oracle Virtual DirectoryのLDAPライセンス・ポートを指定します。
Bind DN: ユーザー・データ・ディレクトリ・サーバーについて、仮想ツリーの任意の場所にあるOracle Virtual Directoryの仮想DNを指定します。たとえば、o=ovd_data,o=usと指定します。
Password: ユーザー・データのバインドDNのパスワードを指定します。
構成データ・ディレクトリ・サーバーの詳細の指定を求められた場合、この実装について次を指定します。
Configuration Data Directory Server: ネイティブ・ディレクトリ・サーバーのタイプ。
構成データ・ディレクトリ・サーバーの詳細:
Host Name: Oracle Access Managerの構成データを格納するネイティブ・ディレクトリをホストしているコンピュータのDNSホスト名。
Port number: 構成データ・ディレクトリ・サーバーがリスニングするポートを指定します。
Bind DN: 構成データ・ディレクトリ・サーバーのバインドDNに対して指定します。
Password: 構成データのバインドDNのパスワード。
通常どおりに最初のアイデンティティ・サーバーのインストールを終了します。
次の項目、「ディレクトリ・スキーマの拡張」に進み、すべての項目を実行します。
|
重要: アイデンティティ・サーバーのインストールと設定は、この実装の最後の作業です。他のすべての作業を先に完了しないと、Oracle Virtual Directoryの実装が失敗する可能性があります。 |
アイデンティティ・システムでは、Personオブジェクト・クラスおよびGroupオブジェクト・クラスの「フルネーム」、「ログイン」および「パスワード」のセマンティク型に割り当てられた属性が必要です。
作業を続行する前に、次の手順を実行する必要があります。
次の場所にある適切なldifファイルを使用して、Oracle Access Managerの属性を使用してバックエンド・ネイティブ・ディレクトリ・スキーマを拡張します。
IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\OblixUserSchema\ directory_user_schema_add.ldif
次の場所にあるVDE_user_schema_add.ldifファイルを使用して、Oracle Access Managerの属性を使用してOracle Virtual Directoryスキーマを拡張します。
IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\OblixUserSchema
VDE_user_schema_add.ldif
ディレクトリ・スキーマの拡張の手順
仮想ディレクトリに含める準備をするバックエンド・ディレクトリ・サーバーのスキーマを拡張するときに使用する、次のようなldifファイルを検索します。
IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\OblixUserSchema
仮想ディレクトリに含める特定のバックエンド・ディレクトリ・サーバーごとに属性を手動で構成するためのガイドとして、表10-6を使用します。
|
注意: 適切な*.ldifファイルがIdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\OblixUserSchemaにない場合、IdentityServer_install_dir\identity\oblix\data\commonにある対応する*.ldifファイルを使用できます。 |
表10-6 Oracle Access Managerの属性を使用してネイティブ・スキーマを拡張するためのファイルおよびコマンド
| ディレクトリ・サーバーおよびldifファイル | スキーマの手動更新コマンド |
|---|---|
|
Active Directory ADUserSchema.ldif または ADAuxSchema.ldif （環境に応じて異なる） |
ldifde -s host -t port -a bind-dn -w password -c fromDN toDN -i -f ADuserSchema.ldif |
|
ADAM ADAM_user_schema_add.ldif または ADAMAuxSchema.ldif （環境に応じて異なる） |
ldifde -s host -t port -a bind-dn -w password -c fromDN toDN -i -f ADAM_user_schema_add.ldif |
|
SunONE
|
ldapmodify -h host -p port -D bind-dn -w password -a -f iplanet_user_schema_add.ldif ldapmodify -h host -p port -D bind-dn -w password -a -f iplanet5_user_index_add.ldif |
|
eDirectory
|
ldapmodify -h host -p port -D bind-dn -w password -a -f NDS_user_schema_add.ldif ldapmodify -h host -p port -D bind-dn -w password -a -f NDS_user_index_add.ldif |
|
IBM
|
ldapmodify -h host -p port -D bind-dn -w password -a -f v3.user.ibm_at.ldif ldapmodify -h host -p port -D bind-dn -w password -a -f v3.user.ibm_oc.ldif |
|
Oracle Internet Directory
|
ldapmodify -h host -p port -D bind-dn -q -a -f OID_user_schema_add.ldif
Please enter bind password:
bind successful
ldapmodify -h host -p port -D bind-dn -q -a -f OID_user_index_add.ldif
Please enter bind password:
bind successful
Oracle Internet Directoryを使用する場合、可能なかぎりLDAP_PASSWORD_PROMPTONLY変数をTRUEまたは1に設定して、安全性の低い-wおよび-P passwordオプションを無効化し、さらに-q（または-Q）オプションを使用して、ユーザー・パスワード（またはウォレット・パスワード）の入力を求めるようにしてください。 |
インストール内のディレクトリ・サーバーごとにこの手順を繰り返します。
|
重要: 既存のOracle Access Managerインストールを使用して作業している場合は、次の手順を使用してOracle Virtual Directoryスキーマを手動で拡張する必要があります。 |
次のように、VDE_user_schema_add.ldifファイルを使用して、Oracle Access Managerの属性を使用してOracle Virtual Directoryスキーマを手動で拡張します。
IdentityServer_install_dir\identity\oblix\tools\\DataAnyWhere\OblixUserSchema\V VDE_user_schema_add.ldif ldapmodify -h host -p port -D bind-dn -w password -a -f VDE_user_schema_add.ldif
次のように、すべてのバックエンド・データ・ソースが示されるようにOracle Virtual Directoryスキーマを拡張します。
バックエンド・ディレクトリの属性をOracle Virtual Directoryスキーマに追加します。
Active Directoryの例: inetOrgPersonオブジェクト・クラスの属性をOracle Virtual DirectoryのinetOrgPersonオブジェクト・クラスに対して更新/追加します。
データベースの例: Oracleの従業員表の属性をinetOrgPersonオブジェクト・クラスに追加します。
または、ネイティブ・データ・ストアから参照可能なすべての属性を持つ新しいオブジェクト・クラスを作成します。
Active Directoryの例: userまたはinetOrgPersonオブジェクト・クラスのすべての必須属性を持つ新しいオブジェクト・クラス（MyCompanyPerson）を作成します。
データベースの例: Oracleの従業員表から参照可能なすべての属性を持つ新しいオブジェクト・クラス（MyCompanyPerson）をinetOrgPersonオブジェクト・クラスに対して作成します。
|
注意: スキーマの拡張を行うには、VDMのユーザー・インタフェース（「VDM」→「Your_Project」→「Your_Server」→「エンジン」→「スキーマ」）を使用します。拡張したスキーマがldifファイル内にある場合、ldapmodifyを使用してこのスキーマをOracle Virtual Directoryインスタンスにロードします。 |
後で開発するデータ・ストア・アダプタに必要なマッピング・ファイルを作成できます。
各マッピング・ファイルにより、バックエンド・スキーマをフロントエンド（Oracle Virtual Directory）スキーマに変換するフィルタが生成されます。
各マッピング・ファイルを使用して、データ・ストアのインバウンドおよびアウトバウンド・データをマップし、不適切なデータを削除できます。
独自のマッピング・ファイルを最初から作成することも、複数のプラグインを含むオラクル社提供のサンプル・ファイルを使用することも可能です。「Oracle Access ManagerとOracle Virtual Directoryの実装のテンプレート」を参照してください。
次の手順では、オラクル社提供のサンプル・ファイルを使用します。ここでは、これらの手順をガイドとして使用します。この手順は、LDAPマッピング・ファイルとRDBMSマッピング・ファイルのどちらでも同じです。
VDMの使用の詳細は、Oracle Virtual Directoryのドキュメントを参照してください。
データ・ストア・アダプタのマッピング・ファイルの作成の手順
「サンプル・アダプタおよびマッピング・テンプレートの取得/更新」の作業を実行し、オラクル社提供のサンプル・マッピング・ファイルを用意します。
VDMのサーバー・ナビゲータ・ウィンドウで、Oracle Virtual Directoryサーバーを選択します。
Oracle Virtual Directoryから「エンジン」を選択し、エンジン・メニューから「マッピング」を選択します。
「マッピング」を右クリックしてから、「新規マッピング」を選択します。
表示される新規マッピング・ウィンドウの「ファイル」リストには、以前にVDMにコピーしたサンプル・マッピング・テンプレートの名前が含まれています。
要求される情報を指定します。
ファイル名: 変更するバージョンを示す一意の名前を入力します。
Server: プロジェクトが含まれるサーバーを指定します。
ファイル・テンプレート: 必要なサンプル・マッピング・テンプレートを選択します。
後で使用するために保持する必要があるサンプル・テンプレートが変更によって上書きされないように、新しい名前を割り当てる必要があります。
「名前」フィールドで、変更するバージョンを示す一意の名前を入力します。
「終了」をクリックします。
名前がウィンドウの左側に表示されます。
Virtual Directory Managerのサーバー・ナビゲータ・ウィンドウで、作成したファイル名を選択し、ウィンドウの右側に表示します。
アイデンティティ・システムのインストールおよび設定を終了する前に、マッピング・ファイルをカスタマイズし、データ・ストア・アダプタに追加する必要があります。マッピング・ファイルはここでカスタマイズすることも、後でカスタマイズすることも可能です。
次のように作業を続行します。
通常どおりにマッピング・ファイルをサーバーにデプロイします。
「データ・ストア・アダプタの作成」に進みます。
マッピング・スクリプトは、必要に応じてここで変更することも、データ・ストア・アダプタを作成した後に変更することもできます。ファイルをカスタマイズしてアダプタに含める場合、「アダプタおよびマッピング・ファイルのカスタマイズ」を参照してください。
オラクル社提供のサンプル・ファイルを使用していない場合、ダミー・ユーザーの作成が必要な場合があります（「予期しないグループ削除の問題」を参照）。
オラクル社提供のサンプル・ファイルを使用している場合、これは自動的に行われます。
ここで、接続するデータ・ストアごとにアダプタを作成する必要があります。
ディレクトリ: 「LDAPディレクトリのアダプタの作成」で説明されているように、LDAPアダプタを作成します。
データベース: 「データベース・アダプタの構成」で説明されているように、データベース・アダプタを作成します。
分割プロファイル: データ・ストアごとに個別のアダプタを作成してから、2つのデータ・ソースを単一のビューに結合するアダプタを作成します。「分割プロファイル・アダプタの作成」を参照してください。
複数のディレクトリ: 「複数ディレクトリのアダプタの作成」で説明されているように、Oracle Virtual Directoryアダプタに各データ・ソースを接続するための個別のアダプタを作成します。
アダプタを最初から作成することもできますが、オラクル社提供のサンプル・テンプレートを使用すると、作業を簡略化できます。オラクル社提供のサンプル・アダプタ・テンプレートを使用する場合、アダプタを作成するために接続および資格証明情報、論理ルート、リモート・ルートなどを入力する必要があります。また、データ・ストアごとに設定を変更および調整する必要もあります。アダプタを作成した後、テンプレートに定義されている情報がこのアダプタに設定されます。
Oracleテンプレートの詳細は、「Oracle Access ManagerとOracle Virtual Directoryの実装のテンプレート」を参照してください。テンプレートの変更の詳細は、「アダプタおよびマッピング・ファイルのカスタマイズ」を参照してください。
ホスト・ディレクトリ・サーバーに関係なく、LDAPアダプタの作成の手順は同じです。最初にLDAPアダプタを作成してから、マッピング・ファイルなどのプラグインを追加します。
次に説明するように、ADAMおよびActive Directoryアダプタには、他のアダプタにはない要件があります。
Active DirectoryおよびADAMアダプタについて: Active DirectoryおよびADAMにはそれぞれ2つのアダプタが必要です。1つは最初に作成する必要があるSSL用のアダプタで、もう1つは2番目に作成する必要があるオープン接続用のアダプタです。オラクル社は、これらのアダプタごとに個別のサンプル・テンプレートを提供しています。この環境の設定には、次の作業が含まれます。
SSL接続用のActive DirectoryまたはADAMアダプタの作成
オープン接続用のActive DirectoryまたはADAMアダプタの作成
Active DirectoryおよびADAMアダプタには2つのプラグインが必要です。オラクル社提供のサンプル・テンプレートを使用する場合、次の2つのプラグインがすでに用意されています。ただし、独自のテンプレートを作成する場合、次の2つのプラグインを手動で追加する必要があります。
Active Directoryのパスワード・プラグイン: Active DirectoryおよびADAMでは、セキュア・モードを使用してパスワードを設定または変更する必要があります。
パフォーマンス上の問題に対応するために、「passCredentialsPassword Only SSL」モードがサポートされています。この場合、通常の操作はオープン接続を使用してアダプタを介して行われますが、パスワードの変更/設定機能に関する操作はSSL接続を使用してアダプタにリダイレクトされます。
|
注意: オラクル社提供のサンプル・テンプレートを使用しない場合、「LDAPのアダプタの作成の手順」で説明されているように、Active Directoryのパスワード・プラグインとして作成するSSLアダプタを作成対象のオープン接続アダプタに追加する必要があります。 |
Active Directoryの範囲属性プラグイン: Active DirectoryおよびADAMでは、Active Directoryの範囲属性プラグインを使用してグループ・ページ問題を処理する必要があります。
このプラグインは、Active Directory/ADAMから返されるすべてのグループ・ページを連結し、この情報を1つの結果としてOracle Virtual Directoryクライアントに返します。
|
注意: オラクル社提供のサンプル・テンプレートを使用する場合、この値を編集してください。オラクル社提供のサンプル・テンプレートを使用しない場合、Active Directoryの範囲属性プラグインを作成し、作成対象のオープン接続アダプタに追加する必要があります。 |
すべてのLDAPディレクトリを対象として1つの汎用手順が用意されています。この例には、ADAM用の2つのアダプタを作成するための手順が含まれています（オラクル社提供の例を使用していない場合）。
|
注意: Active DirectoryまたはADAM用としてオラクル社提供のテンプレートを使用する場合、作成が必要なオープン・コネクタの詳細は、手順17を参照してください。SSLコネクタはOracleテンプレートに含まれています。 |
LDAPのアダプタの作成の手順
「アダプタおよびマッピング・ファイルのカスタマイズ」の作業を実行し、オラクル社提供のサンプル・アダプタ・テンプレートを用意します。
Virtual Directory Managerで、「アダプタ」に移動し、「新規」→「LDAPアダプタ」をクリックし、「アダプタ・コンフィギュレーション」画面を表示します。
「アダプタ・テンプレート」リストから適切なアダプタ・タイプを選択します。
次に例を示します。
アダプタ・テンプレート: OblixADAMSSLAdapterUsingMapper
一意のアダプタ名を入力します。
次に例を示します。
アダプタ名: CustomAdamSSLAdapter
接続するLDAPサーバーのサーバー・アドレス、サーバー・プロキシ・ポートおよびサーバー・プロキシ・バインドDNを入力します。
プロキシ・パスワードおよびパススルー資格証明を指定します。
次に例を示します。
プロキシ・パスワード: xxxxxxxx
パススルー資格証明: 常時
「常時」を指定するとパフォーマンスに影響する可能性がありますが、「バインドのみ」または「なし」を使用するとセキュリティが低下します。
次に、接続オプションを指定します。
|
注意: オラクル社提供のテンプレートやADAMまたはActive Directoryを使用しない場合、オープン接続アダプタのプラグインとして含めるSSLアダプタを作成します。 |
SSLバージョンの接続オプション（オラクル社提供のテンプレートを使用する場合は必要なし）として、次を選択します。
接続オプション: セキュアSSL/TLS
この手順により、データ・ストアに接続され、証明書が自動的にダウンロードされます。
リモート・ベースについては、省略記号（...）のボタンをクリックします。
接続するLDAPディレクトリ・サーバーの検索ベース（ルートDN）を示す画面が表示されます。
この時点で、物理ネームスペースを論理ネームスペースにマップする必要があります。
バックエンド・データ・ストアからリモート物理ネームスペース（検索ベース）を選択します。次に例を示します。
ou=company,c=us,dc=intranet,dc=pspl,dc=co,dc=in
「マップされたネームスペース」フィールドで、Oracle Virtual Directoryの論理ネームスペースを入力します。
たとえば、Oracle Virtual Directoryのルートの接尾辞がo=MyCompany,c=usである場合、次のようなマップされたネームスペースを使用できます。
ou=ADAM,o=MyCompany,c=us
「終了」をクリックします。
新しく作成したLDAPアダプタがサーバー・ナビゲータ・ウィンドウの「アダプタ」リストの下に表示されます。
サーバー・ナビゲータ・ウィンドウで新しいアダプタ名をクリックします。
右側のペインで「ルーティング」タブをクリックします。
これがActive DirectoryまたはADAMのSSLアダプタである場合、「一般設定」で、可視性が内部に設定されていることを確認します。
次に例を示します。
一般設定
可視性: 内部
「終了」をクリックします。
Oracle Access Managerが正常に機能するには、製品で使用されるDN属性（manger、secretary、uniqueMembersなど）が、表示時に論理ビュー形式に変換され、格納時に物理形式に戻される必要があります。
オプション: DN属性:
作成したアダプタをダブルクリックします。
右側のウィンドウで「コンフィギュレーション」タブをクリックします。
「設定」で、すべてのオブジェクト・クラス/表についてOracle Virtual Directory属性のカンマ区切りリストで「DN属性」を指定します。
サーバー・ナビゲータ・ウィンドウでアダプタ名を右クリックし、「サーバーに保存」を選択します。
これで第1アダプタは完了です。この手順を実装内のデータ・ストアごとに繰り返す必要があります。
この手順をADAMの第2アダプタに対して繰り返す必要がある場合、そのときはオープン接続を使用します。
|
注意: 次の手順では、前に作成したSSLアダプタと、ADAMおよびActive Directoryに対して作成が必要なオープン接続アダプタの違いのみを示します。他のすべての仕様は同じです。 |
ADAM/Active Directoryのオープン接続アダプタ: 次の異なる仕様を使用して前の手順を繰り返し、必要なオープン接続アダプタを作成します。次に例を示します。
アダプタ・テンプレート: OblixADAMAdapterUsingMapper
アダプタ名: CustomAdamOpenAdapter
ポート: open_port
接続オプション: （どちらのボックスも選択なし）
検索ベース: SSLアダプタと同じ
可視性: はい
オプション: DN属性: オラクル社提供のサンプル・テンプレートを使用せずに作成したActive DirectoryまたはADAMアダプタの場合、前に作成したSSLアダプタで使用したリストと同じにする必要があります。
作成したActive Directoryアダプタをダブルクリックします。
右側のウィンドウで「コンフィギュレーション」タブをクリックします。
「設定」で、すべてのオブジェクト・クラス/表についてOracle Virtual Directory属性のカンマ区切りリストで「DN属性」を指定します。
通常どおり保存およびデプロイします。
次のように作業を続行します。
「マッピング・ファイルを参照するためのアダプタ・プラグインの編集」を参照してください。
「アダプタおよびマッピング・ファイルのカスタマイズ」も参照してください。
必要に応じてその他のLDAPアダプタを作成するか、次に説明するようにデータベース・アダプタを作成します。
使用環境とは関係ない場合、この手順はスキップできます。
次の手順は一般的な例です。これらは環境によって異なります。
データベース・アダプタの構成の手順
「RDBMS用のJDBCドライバ・ライブラリのデプロイ」の作業を実行します。
Virtual Directory Managerで、「アダプタ」→「新規」→「データベース・アダプタ」を選択し、「アダプタ・コンフィギュレーション」画面を表示します。
「データベース・テンプレート: OblixDBAdapterUsingScript」に記載されているOblixDBAdapterUsingScriptを選択します。
一意のアダプタ名を入力します。
マッピング用の論理ネームスペースDNを入力します。
「事前定義済データベースの使用」を選択します。
接続するデータベースのタイプ（MS SQL Serverなど）を選択します。
データベース・サーバーのホスト、ポート、データベース名、ユーザー名およびパスワードを入力します。
「接続の検証」をクリックして接続情報が正しいかどうかを確認し、「次へ」をクリックします。
環境に応じて次に進みます。
その他のテンプレート: オラクル社提供のテンプレートを使用していない場合、説明に従って手順11、12、13および14を実行します。
オラクル社提供のテンプレート: 手順11、12、13および14でオラクル社提供の「データベース・テンプレート: OblixDBAdapterUsingScript」を使用する場合、「次へ」をクリックするのみです。
「データベース・アダプタ・マッピング: 表の選択」画面で、次の手順を実行します。
使用する表を左側のペインから選択します。
「>」をクリックして右側のペインに移動します。
「次へ」をクリックします。
「データベース・アダプタ・マッピング: 結合のビルド」画面は、「次へ」をクリックしてスキップします。
「データベース・アダプタ・マッピング: 属性のマップ」画面で、次の手順を実行します。
前に指定した論理DNをクリックします。
「追加」をクリックし、階層を追加します。
ポップアップ・ウィンドウで、次の作業を実行します。
オブジェクト・クラスで、マップ先のLDAPオブジェクト・クラス（inetorgpersonなど）を入力します。
「RDN」フィールドで、RDN属性名（cnなど）を入力します。
「OK」をクリックします。
「データベース・アダプタ・マッピング: 属性のマップ」画面で、次の手順を実行します。
作成したノード（cn= inetorgpersonなど）をクリックします。
「追加」をクリックします。
ポップアップ・ウィンドウで、ldap属性、表名および表の列を選択します。
LDAP属性名が（obuseraccountcontrolなど）がリストにない場合、入力できます。
マップ対象のすべての属性がマップされるまでこの作業を続行します。
|
注意: Oracle Access Managerが正常に動作するには、少なくともcn、uid、passwordおよびobuseraccountcontrolフィールドをマップする必要があります。obuseraccountcontrolがアクティブであることを確認してください。 |
passwordおよびobuseraccountcontrol列が既存の表に含まれていない場合、これらの列を表に追加します。
「終了」をクリックします。
これで、新しく作成したDBアダプタがサーバー・ナビゲータ・ウィンドウの「アダプタ」リストの下に表示されます。
サーバー・ナビゲータ・ウィンドウでアダプタ名を右クリックし、「サーバーに保存」を選択します。
「ブラウザ」ペインで「クライアント」ビューを確認し、構成を検証します。
すべての環境が対象: 次のように作業を続行します。
「アダプタおよびマッピング・ファイルのカスタマイズ」も参照してください。
「マッピング・ファイルを参照するためのアダプタ・プラグインの編集」で説明されているように、マッピング・ファイルをこのアダプタに追加します。
次に示すように、その他のアダプタを作成します。
分割プロファイルでは、同じユーザーの様々な属性が異なるディレクトリ・サーバーに格納されています。
プライマリ・データ・ストアには重要な属性が含まれ、セカンダリ・データ・ストアにはオプションの属性が含まれます。たとえば、2つの異なるディレクトリ・サーバー・タイプおよびRDBMSがあるとします。この場合、分割プロファイル・アダプタを作成してこれらのビューを結合する必要があります。
分割プロファイル・アダプタを作成するには、個々のデータ・ストア・アダプタを作成する必要があります。プライマリ・アダプタとセカンダリ・アダプタではそれぞれ「可視性」を「内部」に設定し、Oracle Virtual Directoryからのみこれらが認識できるようにする必要があります。
分割プロファイル・アダプタを作成する場合、プライマリ・アダプタおよびこのプライマリ・アダプタに対するバインド対象を識別します。分割プロファイル・アダプタを作成した後、プライマリ・アダプタおよび結合対象の第1セカンダリ・アダプタを識別する結合ルールを指定します。結合ルールを指定する場合、プライマリ・アダプタを複数のセカンダリ・アダプタに結合するよう指定できます（1対多）。
|
注意: オラクル社は、結合ビュー・アダプタ・テンプレートを提供しています。 |
分割プロファイルの検索ベース（Oracle Virtual Directoryはこれをルート・ベースとして参照）は、プライマリ・ディレクトリの検索ベースと同じである必要があります。
分割プロファイル・アダプタの論理ビューがプライマリ・データ・ストアと同じであることを確認する必要があります。分割プロファイル・アダプタは、プライマリ論理ビューのDN属性値を分割プロファイル論理ビュー（またはこの逆）にマップしません。
後述の手順では、結合ビュー方式を使用して一般的な方法について説明します。詳細は、Oracle Virtual Directoryのドキュメントを参照してください。この例では、ADAMがプライマリ・アダプタ、Sunがセカンダリ・アダプタとして使用されています。この場合、ADAM用として作成したオープン接続アダプタを使用します。これは、このアダプタには、SSLアダプタを含む適切なプラグインが含まれるためです。これらは環境によって異なります。
分割プロファイル・アダプタの作成の手順
「LDAPディレクトリのアダプタの作成」で説明されているように、結合するデータ・ストアごとにアダプタを作成します。
Virtual Directory Managerのサーバー・ナビゲータ・ウィンドウで、Oracle Virtual Directoryサーバーを選択し、「エンジン」を選択します。
「アダプタ」を右クリックし、「新規」を選択して「結合ビュー・アダプタ」を選択します。
ダイアログ・ボックスの「アダプタ・テンプレート」で、デフォルトの結合ビュー・テンプレートを選択します。
「アダプタ名」フィールドで、カスタマイズしたバージョンを示す一意の名前を入力します。
次に例を示します。
アダプタ名: CustomJoinADAMSun
「アダプタ接尾辞/ネームスペース」リストで、プライマリ・アダプタのDNと同じネームスペース（ベースDN）を入力します。
この例では、プライマリ・アダプタはADAMです。SSLアダプタがプラグインとして含まれるオープン接続アダプタの名前を指定する必要があります。
「プライマリ・アダプタ」フィールドで、プライマリ・アダプタを選択します。
次に例を示します。
プライマリ・アダプタ: CustomAdamAdapter
「バインド・アダプタ」リストで、同じアダプタを選択します。
次に例を示します。
バインド・アダプタ: CustomAdamAdapter
「終了」をクリックします。
アダプタ名が左側のペインに表示され、結合ビュー・プライマリ・アダプタ構成ウィンドウが右側に表示されます。
結合ビュー・プライマリ・アダプタ構成ウィンドウの「設定」領域で、プライマリおよびバインディング・アダプタの設定を入力します。
次に例を示します。
設定
プライマリ・アダプタ: CustomAdamAdapter
バインド・アダプタ: CustomAdamAdapter
「ルールの結合」の横にある「新規」ボタンをクリックし、「結合ルールの入力」ダイアログを表示します。
「結合ルールの入力」ダイアログで、結合するセカンダリ・アダプタを選択し、環境に応じたタイプ・クラスおよび条件を選択します。
次に例を示します。
結合済アダプタ: CustomSunAdapter
タイプ/クラス: 1対多ジョイナ
条件: cn=cn
別のアダプタを結合する場合は手順12を繰り返し、結合しない場合はこの手順はスキップします。
サーバー・ナビゲータ・ウィンドウでアダプタ名を右クリックし、「サーバーに保存」を選択します。
ブラウザ・ウィンドウで新しい構成、「クライアント・ビュー」を確認します。
Oracle Virtual Directoryの背後に複数のディレクトリ・サーバーがある場合、次に示すように、Oracle Virtual Directory内にローカル・データ・ストア・アダプタのエントリを作成し、アイデンティティ・システムの検索ベースとして使用されるOracle Virtual Directoryの仮想ルート用のエントリを追加する必要があります。
タスクの概要: 複数ディレクトリのアダプタの作成
次に示すように、結合するデータ・ストアごとにアダプタを作成します。
各ディレクトリ・サーバーによって同じ検索ベースが使用され、複数ディレクトリのアダプタがルートであることを確認します。
「ローカル・データ・ストア・アダプタの作成」の作業を実行します。
「仮想ルートの物理ノードの作成」の作業を実行します。
Oracle Access Managerでローカル・ストア・アダプタが必要になるのは、複数のアダプタのエントリの親エントリである仮想エントリを作成し、1つの連続したツリーが存在するように見えるようにする場合のみです。
たとえば、2つのディレクトリがあり、これらのディレクトリが含まれるディレクトリ・ツリーを作成するとします。
ディレクトリ1: ou=Marketing,o=Company
ディレクトリ2: ou=Product,o=Company
このような条件で、o=Companyレベルから検索し、ディレクトリ1とディレクトリ2の両方を網羅する検索を行う場合、ローカル・ストア・アダプタを使用し、1つのエントリo=Companyを唯一のエントリとして作成できます。これにより、次のような完全ツリーが生成されます。
o=Company: Oracle Access Managerはここから検索可能
/ \
ou=Marketing ou=Product
ローカル・データ・ストア・アダプタが必要なのは、次の場合のみです。
個々のすべてのデータ・ストア・アダプタを対象とした統合検索ベースが必要な場合
個々のすべてのデータ・ストア・アダプタのルート検索ベースが同じ場合
データ・ストアのエントリが重複していない（重複エントリが削除されているか、フィルタを使用して除外されている）場合
次の手順は一般的な手順です。詳細は、Oracle Virtual Directoryのドキュメントを参照してください。
Oracle Virtual Directoryのアダプタ・エントリの作成の手順
Virtual Directory Managerで、「アダプタ」に移動します。
「アダプタ」を右クリックします。
「新規」→「ローカル・ストア・アダプタ」を選択し、「アダプタ・コンフィギュレーション」画面を表示します。
アダプタの接尾辞（すべてのアダプタの共通仮想ルート・ベース）を指定します。
通常どおりサーバーに保存します。
「仮想ルートの物理ノードの作成」に進みます。
複数のディレクトリ用のローカル・データ・ストア・アダプタのエントリを作成した後、Oracle Virtual Directoryディレクトリに物理ノードを作成する必要があります。これは、アイデンティティ・システム設定によって構成ノードがグローバル検索ベースとして読み取られるためです。仮想ルートの物理ノードは、通常どおりにldpユーティリティを使用して作成します。
Virtual Directory Managerの使用の詳細は、Oracle Virtual Directoryのドキュメントを参照してください。
仮想ルートの物理ノードの作成の手順
ldpまたはldapmodifyユーティリティを検索します。
Oracle Virtual Directoryの仮想ルートのエントリを追加します。
たとえば、仮想ルートがo=Company, c=usである場合、次のエントリを追加します。
dn:o=Company,c=us
Objectclass: organization
o: Company
各ディレクトリ・サーバーによって同じ検索ベースが使用され、複数ディレクトリのアダプタがルートであることを確認します。
次の項では、Oracle Access Managerの使用方法に関する仕様について説明します。
前述の説明のとおり、独自のテンプレートを最初から作成することも、オラクル社提供のサンプルをカスタマイズすることもできます。オラクル社提供のサンプルには、次の2つのタイプがあります。
サンプル・アダプタ・テンプレート: ネイティブ・データ・ストアをOracle Virtual Directoryに接続する個々のアダプタの基準として使用可能なベンダー固有のアダプタ・ファイルのサンプル・テンプレート。
|
注意: オラクル社提供のサンプル・テンプレートは、1つのデータ・ストアと特定のユーザー定義のスキーマの両方に固有のテンプレートです。これらは環境によって異なります。 |
サンプル・マッピング・ファイル: Oracle Virtual Directoryが、ネイティブ・データ・ストアによって使用されるスキーマ（またはデータベース・フィールド）を、Oracle Access Managerから参照する集約仮想ディレクトリによって使用される論理スキーマに変換できるようにするためのサンプル・マッピング・ファイル。
次の例は、環境に応じて作成可能なオラクル社提供のサンプルに対する変更のタイプを示します。これらの例に含まれる情報および特定の変更内容は、説明のみを目的としています。これらは環境によって異なります。
この項の例は、Active Directoryディレクトリ・サーバーのマッピング・ファイルのカスタマイズ・バージョンを示します。この例は、Active Directoryディレクトリ・サーバー用としてオラクル社提供のサンプル・テンプレートと、ここには含まれていない特定のユーザー定義のスキーマから開始します。
|
注意: DN変換ツールキットは、アイデンティティ・サーバー・インストールの一部として自動的にインストールされます。IdentityServer_install_dir\identity\oblix\tools\DataAnyWhereを参照してください。 |
Active Directoryに対して行われたマッピング・スクリプトの変更タイプの確認の手順
Virtual Directory Managerコンソールで、サンプルのOblixADMappingファイルをベースとして使用してマッピング・ファイルを作成します（「アダプタのマッピング・ファイルの作成」を参照）。
IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\plugins\
OracleAccessmanagerOViDTemplates\mapping_templates\OblixADMapping_mpy.xml
環境に応じてマッピング・ファイルを変更し、手順4の下に示されるActive Directory用のマッピング・ファイルとこのカスタマイズ・バージョンを比較します。
マッピング・スクリプトを通常どおり保存およびデプロイします。
マッピング・スクリプトを後で使用するためのテンプレートとして保存します。
新しいマッピング・テンプレート名（MyADMappingなど）を右クリックします。
「テンプレートとして保存」を選択します。
<?xml version="1.0" encoding="UTF-8" ?> ...
# Mapping template for: Custom Data sets
#
# Target DS: AD : - using static Auxiliary objectclass
# Target user objectclasses: User and group
# Target custom schema:
# AD_custom_schema_add.ldif
# AD.NET_custom_schema_add.ldif
#
# Functions:
# a. maps AD user to inetOrgPerson
# b. maps AD group to groupofuniquenames
# c. filters out auxiliary class from objectclass in add/modify
# d. filter out AD system attributes
# e. set native flag useraccountcontrol when user is activated/deactivated
# f. set grouptype to 8
#
def inbound():
#first rename the attributes
renameAttribute({'uniqueMember':'member','owner':'managedby','uid':'samaccountname'})
renameAttribute({'carlicense':'gencarlicense','departmentnumber':'gendepartmentnumber'})
#temporary.
removeAttribute('nsaccountlock')
#map object class names
revalueAttribute('objectclass','groupofUniqueNames','group')
revalueAttribute('objectClass','inetOrgPerson','user')
#If static auxiliary class is used on AD, AD does not like to mention
#the auxiliary classes in the objectclass attribute. If dynamic auxiliary
#class is used on AD, comment these out.
removeAttributeValue('objectclass','person')
removeAttributeValue('objectclass','organizationalPerson')
#removeAttributeValue('objectclass','inetOrgPerson')
removeAttributeValue('objectclass','oblixOrgPerson')
removeAttributeValue('objectclass','oblixpersonpwdpolicy')
removeAttributeValue('objectclass','oblixadvancedgroup')
removeAttributeValue('objectclass','oblixgroup')
removeAttributeValue('objectclass','oblixAuxLocation')
#--- Remove custom data auxiliary object classes
removeAttributeValue('objectclass','genAuxLocation')
removeAttributeValue('objectclass','genAuxUserEquipment')
removeAttributeValue('objectclass','genAuxUserNetwork')
removeAttributeValue('objectclass','genAuxUserPersonal')
removeAttributeValue('objectclass','genAuxUserSecurity')
#If static auxiliary class is used in AD, remove the objectclass attribute
#during modify. AD does not like the mentioning of the auxiliary class.
if operation == 'modify':
removeAttribute('objectClass')
#set the native flag useraccountcontrol based on the value of obuseraccountcontrol.
if haveAttribute('obuseraccountcontrol'):
copyAttribute('obuseraccountcontrol','userAccountControl')
#during modify, read the user entry first.
if operation == 'modify':
currentUser = getByName(name)
val = int(`getAttributeValues(currentUser,'userAccountControl')[0]`)
else:
val = 546
#Deactivate - set the 2nd bit
revalueAttribute('userAccountControl','ObWfPendingActivate',`val | 0x0002`)
revalueAttribute('userAccountControl','DEACTIVATED',`val | 0x0002`)
revalueAttribute('userAccountControl','ObWfPendingDeactivate',`val | 0x0002`)
#Activate - set the 2nd bit
revalueAttribute('userAccountControl','ACTIVATED',`val & ~0x0002`)
#when adding a group entry, add the grouptype and samaccountname.
#groupType is hard coded here. If multiple group types are to be supported,
#configured grouptype in VDE for user to enter.
if operation == 'add':
if haveAttributeValue('objectClass','group'):
addAttributeValue('groupType','8')
if not haveAttribute('samaccountname'):
copyAttribute('cn','samaccountname')
#remove these attributes as they are not in AD group. It is better not
#configure them in COREid if not used.
#removeAttribute ('businessCategory')
removeAttribute ('seeAlso')
removeAttribute ('o')
#if haveAttributeValue('objectClass','user'):
#removeAttributeValue('objectclass','person')
#removeAttributeValue('objectclass','organizationalPerson')
#removeAttributeValue('objectclass','inetOrgPerson')
if operation == 'modify':
currentEntry = getByName(name)
val = getAttributeValues(currentEntry,'objectclass')
if DirectoryString('group') in val:
#removeAttribute ('businessCategory')
removeAttribute ('seeAlso')
removeAttribute ('o')
#filter out obgroupcreator otherwise iplanet user cannot create ad group.
if haveAttribute ('obgroupcreator'):
removeAttribute ('obgroupcreator')
return
def outbound():
#first rename the attributes
renameAttribute({'member':'uniqueMember','managedby':'owner','samaccountname':'uid'})
renameAttribute({'gencarlicense':'carlicense','gendepartmentnumber':'departmentnumber'})
#map object class names
revalueAttribute('objectClass','group','groupofUniqueNames')
revalueAttribute('objectClass','user','inetOrgPerson')
#filter out AD system atrributes
removeAttribute ('allowedAttributes')
removeAttribute ('allowedAttributesEffective')
removeAttribute ('allowedChildClasses')
removeAttribute ('allowedChildClassesEffective')
removeAttribute ('assistant')
removeAttribute ('bridgeheadServerListBL')
removeAttribute ('canonicalName')
removeAttribute ('createTimeStamp')
removeAttribute ('department')
removeAttribute ('distinguishedName')
removeAttribute ('dSASignature')
removeAttribute ('dSCorePropagationData')
removeAttribute ('extensionName')
removeAttribute ('flags')
removeAttribute ('fromEntry')
removeAttribute ('frsComputerReferenceBL')
removeAttribute ('fRSMemberReferenceBL')
removeAttribute ('fSMORoleOwner')
removeAttribute ('generationQualifier')
removeAttribute ('instanceTyp')
removeAttribute ('isCriticalSystemObject')
removeAttribute ('isDeleted')
removeAttribute ('isPrivilegeHolder')
removeAttribute ('lastKnownParent')
removeAttribute ('managedObjects')
removeAttribute ('modifyTimeStamp')
removeAttribute ('mS-DS-ConsistencyChildCount')
removeAttribute ('mS-DS-ConsistencyGuid')
removeAttribute ('name')
removeAttribute ('netbootSCPBL')
removeAttribute ('nonSecurityMemberBL')
removeAttribute ('nTSecurityDescriptor')
removeAttribute ('objectCategory')
removeAttribute ('objectGUID')
removeAttribute ('objectVersion')
removeAttribute ('partialAttributeDeletionList')
removeAttribute ('partialAttributeSet')
removeAttribute ('possibleInferiors')
removeAttribute ('queryPolicyBL')
removeAttribute ('replPropertyMetaData')
removeAttribute ('replUpToDateVector')
removeAttribute ('revision')
removeAttribute ('sDRightsEffective')
removeAttribute ('serverReferenceBL')
removeAttribute ('showInAdvancedViewOnly')
removeAttribute ('siteObjectBL')
removeAttribute ('subRefs')
removeAttribute ('subSchemaSubEntry')
removeAttribute ('systemFlags')
removeAttribute ('uSNChanged')
removeAttribute ('uSNCreated')
removeAttribute ('uSNDSALastObjRemoved')
removeAttribute ('USNIntersite')
removeAttribute ('uSNLastObjRem')
removeAttribute ('uSNSource')
removeAttribute ('wbemPath')
removeAttribute ('wellKnownObjects')
removeAttribute ('whenChanged')
removeAttribute ('whenCreated')
removeAttribute ('instanceType')
removeAttribute ('ms-sql-olapcube')
removeAttribute ('ms-sql-database')
removeAttribute ('ms-sql-server')
removeAttribute ('ms-sql-sqlpublication')
removeAttribute ('ms-sql-sqldatabase')
removeAttribute ('ms-sql-sqlrepository')
removeAttribute ('ms-sql-sqlserver')
removeAttribute ('acpolity')
removeAttribute ('acsubnet')
removeAttribute ('msexchconfigurationcontainer')
removeAttribute ('msmqconfiguration')
removeAttribute ('msmqenterprisesettings')
removeAttribute ('msmqmigrateduser')
removeAttribute ('msmqqueue')
removeAttribute ('msmqsettings')
removeAttribute ('msmqsitelink')
removeAttribute ('ntdsconnection')
removeAttribute ('ntdsdsa')
removeAttribute ('ntdsservice')
removeAttribute ('ntdssitesettings')
removeAttribute ('ntfrsmember')
removeAttribute ('ntfrsreplicaset')
removeAttribute ('ntfrssettings')
removeAttribute ('ntfrssubscriber')
removeAttribute ('ntfrssubscriptions')
removeAttribute ('accountExpires')
removeAttribute ('aCSPolicyName')
removeAttribute ('adminCount')
removeAttribute ('badPasswordTime')
removeAttribute ('badPwdCount')
removeAttribute ('codePage')
removeAttribute ('controlAccessRights')
removeAttribute ('dBCSPwd')
removeAttribute ('defaultClassStore')
removeAttribute ('desktopProfile')
removeAttribute ('dynamicLDAPServer')
removeAttribute ('groupMembershipSAM')
removeAttribute ('groupPriority')
removeAttribute ('groupsToIgnore')
removeAttribute ('homeDirectory')
removeAttribute ('homeDrive')
removeAttribute ('lastLogoff')
removeAttribute ('lastLogon')
removeAttribute ('lmPwdHistory')
removeAttribute ('localeID')
removeAttribute ('lockoutTime')
removeAttribute ('logonCount')
removeAttribute ('logonHours')
removeAttribute ('logonWorkstation')
removeAttribute ('mSMQDigests')
removeAttribute ('mSMQDigestsMig')
removeAttribute ('mSMQSignCertificates')
removeAttribute ('mSMQSignCertificatesMig')
removeAttribute ('msNPAllowDialin')
removeAttribute ('msNPCallingStationID')
removeAttribute ('msNPSavedCallingStationID')
removeAttribute ('msRADIUSCallbackNumber')
removeAttribute ('msRADIUSFramedIPAddress')
removeAttribute ('msRADIUSFramedRoute')
removeAttribute ('msRADIUSServiceType')
removeAttribute ('msRASSavedCallbackNumber')
removeAttribute ('msRASSavedFramedIPAddress')
removeAttribute ('msRASSavedFramedRoute')
removeAttribute ('networkAddress')
removeAttribute ('ntPwdHistory')
removeAttribute ('operatorCount')
removeAttribute ('otherLoginWorkstations')
removeAttribute ('preferredOU')
removeAttribute ('primaryGroupID')
removeAttribute ('profilePath')
removeAttribute ('pwdLastSet')
removeAttribute ('scriptPath')
removeAttribute ('servicePrincipalName')
removeAttribute ('userAccountControl')
removeAttribute ('userParameters')
removeAttribute ('userSharedFolder')
removeAttribute ('userSharedFolderOther')
removeAttribute ('userSMIMECertificate')
removeAttribute ('userWorkstations')
removeAttribute ('masteredBy')
removeAttribute ('maxStorage')
removeAttribute ('userPrincipalName')
removeAttribute ('objectSid')
removeAttribute ('samaccounttype')
removeAttribute ('badPasswordCount')
removeAttribute ('sAMAccountControl')
removeAttribute ('ADsPath')
removeAttribute ('directReport')
return
</ldap>
</adapters>
この項の例は、ユーザー定義のスキーマとともにバックエンドとしてSQLサーバーを使用するOracleデータベース用としてカスタマイズされた後のサンプルのOblixDBMappingファイルを示します。元のサンプルは次の場所にあります。
IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\plugins\
OracleAccessmanagerOViDTemplates\mapping_templates\OblixDBMapping_mpy.xml
|
注意: DN変換ツールキットは、アイデンティティ・サーバー・インストールの一部として自動的にインストールされます。IdentityServer_install_dir\identity\oblix\tools\DataAnyWhereを参照してください。ツールキットに付属しているREADMEファイルを必ず参照してください。 |
オラクル社提供の元のサンプルを次のマッピング・ファイルと比較すると、必要な変更のタイプを確認できます。
Oracleデータベース用のマッピング・スクリプトの変更の確認の手順
Virtual Directory Managerコンソールで、サンプルのOblixDBMappingファイルをベースとして使用してマッピング・ファイルを作成します（「アダプタのマッピング・ファイルの作成」を参照）。
環境に応じてマッピング・ファイルを変更し、「予期しないグループ削除の問題」の例に示されている対策を講じます。
マッピング・スクリプトを通常どおり保存およびデプロイします。
マッピング・スクリプトを後で使用するためのテンプレートとして保存します。
新しいマッピング・テンプレート名（MyOracleDBMappingなど）を右クリックします。
「テンプレートとして保存」を選択します。
次に、Oracleデータベース用のアダプタのカスタマイズも参照してください。
<?xml version="1.0" encoding="UTF-8"?>
<variables>
</variables>
<content>
def inbound():
#These Oblix attributes are not being used. Remove them.
removeAttribute('obver')
removeAttribute('nsaccountlock')
# More custom mapping
# ....
# If your user password is stored as character type, for example
# NVARCHAR, CHAR, VARCHAR, etc, you need to map userPassword attribute
# from binary syntax.
mapSyntax('userPassword','IA5String')
# This is a workaround ... for more information, see " "Unexpected Group Deletion Problem".
# Need to prevent COREid from writing dummy user to backend database
if haveAttributeValue('uniqueMember','cn=Dummy User'):
#removeAttributeValue('uniqueMember','cn=Dummy User')
if operation != 'modify':
removeAttributeValue('uniqueMember','cn=Dummy User')
else:
change = removeAttribute('uniqueMember')[0]
change.values.remove(DistinguishedName('cn=Dummy User'))
addEntryChange(change)
#Filter out objectclass. Only mention the structure class during add.
if operation == 'modify':
removeAttribute('objectClass')
if operation == 'add':
newobj = ''
if haveAttributeValue('objectClass','inetOrgPerson'):
newobj = 'inetOrgPerson'
if haveAttributeValue('objectClass','groupOfUniqueNames'):
newobj = 'groupOfUniqueNames'
removeAttribute ('businessCategory')
removeAttribute ('seeAlso')
removeAttribute ('o')
if haveAttributeValue('objectClass','oblixlocation'):
newobj = 'oblixlocation'
if not newobj == '':
removeAttribute('objectClass')
addAttributeValue('objectClass',newobj)
return
def outbound():
#code here for handling outbound mapping
# .....
# This is a workaround to bug #18865
if operation=='entry':
# Add the following workaround for each multiple value DN attribute
if haveAttribute('uniqueMember') and len(findFilters('uniqueMember')) > 0:
addAttributeValue('uniqueMember','cn=Dummy User')
return
</content>
次の例は、Oracleデータベース用としてカスタマイズしたサンプル・アダプタを示します。オラクル社提供のサンプル・テンプレートがベースとして使用されています。
<?xml version="1.0" encoding="UTF-8"?>
<adapters dirty="" version="0"
xmlns="http://www.octetstring.com/schemas/Adapters" xmlns:adapters="http:// www.w3.org/2001/XMLSchema-instance">
<dataBase dirty="" id="DB Adapter Company Employees" version="0">
<root>ou=Employees,o=MyCompanyDB,c=us</root>
<active>true</active>
<routing>
<critical>true</critical>
<priority>50</priority>
<inclusionFilter/>
<exclusionFilter/>
<plugin/>
<retrieve/>
<store>
<exclude>carlicense</exclude>
<exclude>street</exclude>
<exclude>employeeType</exclude>
</store>
<visible>Internal</visible>
<levels>-1</levels>
<bind>true</bind>
<bind-adapters/>
<views/>
<dnpattern/>
</routing>
<pluginChains xmlns="http://www.octetstring.com/schemas/Plugins">
<plugins>
<plugin>
<name>MyOracleDBMapping</name>
<class>com.octetstring.VDE.chain.plugins.mapper.Mapper</class>
<initParams>
<param name="mapfile" value="MyOracleDBMapping.mpy"/>
</initParams>
</plugin>
<plugin>
<name>Dump after</name>
<class>com.octetstring.VDE.chain.plugins.DumpTransactions.DumpTransactions</ class>
<initParams>
<param name="loglevel" value="info"/>
</initParams>
</plugin>
<plugin>
<name>Dump before</name>
<class>com.octetstring.VDE.chain.plugins.DumpTransactions.DumpTransactions</ class>
<initParams>
<param name="loglevel" value="info"/>
</initParams>
</plugin>
</plugins>
<default>
<plugin name="Dump before"/>
<plugin name="MyOracleDBMapping"/>
<plugin name="Dump after"/>
</default>
</pluginChains>
<driver>oracle.jdbc.driver.OracleDriver</driver>
<url>jdbc:oracle:thin:@127.0.0.1:1521:QA2</url>
<user>CUSTDATA</user>
<password>oblix</password>
<ignoreObjectClassOnModify>false</ignoreObjectClassOnModify>
<includeInheritedObjectClasses>true</includeInheritedObjectClasses>
<maxConnections>10</maxConnections>
<mapping>
<joins/>
<objectClass name="inetOrgPerson" rdn="cn">
<attribute field="EMPLOYEE_ID" ldap="uid"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="NAME" ldap="cn" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="FIRST_NAME" ldap="givenName"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="LAST_NAME" ldap="sn"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="TITLE" ldap="title" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="USERPASSWORD" ldap="userPassword"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="PREFERREDLANGUAGE"
ldap="PreferredLanguage" table="CUSTDATA.EMPLOYEES" type="CHAR"/>
<attribute field="MAIL" ldap="mail" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="CHALLENGEPHRASE" ldap="ChallengePhrase"
table="CUSTDATA.EMPLOYEES" type="CHAR"/>
<attribute field="PHOTO" ldap="Photo"
table="CUSTDATA.EMPLOYEES" type="BLOB"/>
<attribute field="DESCRIPTION" ldap="Description"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="OBUSERACCOUNTCONTROL"
ldap="OBUSERACCOUNTCONTROL" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="OBLOGINTRYCOUNT" ldap="oblogintrycount"
table="CUSTDATA.EMPLOYEES" type="NUMERIC"/>
<attribute field="OBPASSWORDCREATIONDATE"
ldap="obpasswordcreationdate" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/ >
<attribute field="OBPASSWORDHISTORY" ldap="obpasswordhistory"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="OBPASSWORDCHANGEFLAG"
ldap="obpasswordchangeflag" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="OBPASSWORDEXPMAIL" ldap="obpasswordexpmail"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="OBLOCKOUTTIME" ldap="oblockouttime"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="OBFIRSTLOGIN" ldap="obfirstlogin"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="OBRESPONSETRIES" ldap="obresponsetries"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="OBLASTLOGINATTEMPTDATE"
ldap="oblastloginattemptdate" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/ >
<attribute field="OBLASTRESPONSEATTEMPTDATE"
ldap="oblastresponseattemptdate" table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="OBRESPONSETIMEOUT" ldap="obresponsetimeout"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
<attribute field="MANAGER_DN" ldap="Manager"
table="CUSTDATA.EMPLOYEES" type="VARCHAR"/>
</objectClass>
<objectClass name="groupOfUniqueNames" rdn="cn">
<attribute field="GROUP_NAME" ldap="cn"
table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OWNER_DN" ldap="owner"
table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="MEMBER_DN" ldap="uniqueMember"
table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="MAIL" ldap="mail" table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBGROUPCREATOR" ldap="obgroupcreator"
table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBGROUPCREATIONDATE"
ldap="obgroupcreationdate" table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBGROUPTYPE" ldap="obgrouptype"
table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBSUBSCRIPTIONTYPES"
ldap="obsubscriptiontypes" table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBVER" ldap="obver"
table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBGROUPSUBSCRIPTIONTYPE"
ldap="obgroupsubscriptiontype" table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBGROUPEXPANDEDDYNAMIC"
ldap="obgroupexpandeddynamic" table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBGROUPPUREDYNAMIC" ldap="obgrouppuredynamic"
table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBGROUPADMINISTRATOR"
ldap="obgroupadministrator" table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBGROUPSUBSCRIBEMESSAGE"
ldap="obgroupsubscribemessage" table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBGROUPUNSUBSCRIBEMESSAGE"
ldap="obgroupunsubscribemessage" table="CUSTDATA.GROUPS" type="VARCHAR"/ >
<attribute field="OBGROUPSUBSCRIPTIONFILTER"
ldap="obgroupsubscriptionfilter" table="CUSTDATA.GROUPS" type="VARCHAR"/ >
<attribute field="OBGROUPSUBSCRIBENOTIFICATION"
ldap="obgroupsubscribenotification"
table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBGROUPDYNAMICFILTER"
ldap="obgroupdynamicfilter" table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="OBGROUPSIMPLIFIEDACCESSCONTROL"
ldap="obgroupsimplifiedaccesscontrol "
table="CUSTDATA.GROUPS" type="VARCHAR"/>
<attribute field="GROUP_DESC" ldap="description"
table="CUSTDATA.GROUPS" type="VARCHAR"/>
</objectClass>
<objectClass name="oblixlocation" rdn="obid">
<attribute field="OBID" ldap="obid"
table="CUSTDATA.OBLIXLOCATION" type="VARCHAR"/>
<attribute field="OBLOCATIONNAME" ldap="oblocationname"
table="CUSTDATA.OBLIXLOCATION" type="VARCHAR"/>
<attribute field="OBLOCATIONTITLE" ldap="oblocationtitle"
table="CUSTDATA.OBLIXLOCATION" type="VARCHAR"/>
<attribute field="OBPARENTLOCATIONDN" ldap="obparentlocationdn"
table="CUSTDATA.OBLIXLOCATION" type="VARCHAR"/>
<attribute field="OBRECTANGLE" ldap="obrectangle"
table="CUSTDATA.OBLIXLOCATION" type="VARCHAR"/>
<attribute field="OBPHOTO" ldap="obphoto"
table="CUSTDATA.OBLIXLOCATION" type="BLOB"/>
</objectClass>
</mapping>
</dataBase>
</adapters>
一般的なアダプタ構成および設定情報は、Oracle Virtual Directory/Virtual Directory Managerの製品マニュアルに記載されています。アダプタの作成後、ほとんどの設定でデフォルト値が有効になります。次の重要事項は、Oracle Access Managerに関するものです。
DN属性
接続情報
DN属性:
DN属性は、DN構文に準拠する属性名を使用して設定する必要があります。
これらのDN属性は、顧客スキーマに存在する場合や、Oracle Access Managerの補助クラスによって取り入れられる場合があります。これにより、Oracle Virtual Directoryは、これらのDNの値を論理フォームではなくネイティブ・フォームで格納します。
DN属性は、使用するオブジェクト・クラスと関連しています。
inetorgpersonおよびgroupofuniquenamesの場合、次を使用します。
uniquemember、manager、secretary、owner
userおよびgroupの場合、次を使用します。
member、memberOf、managedObjects、distinguishedname、objectcategory、manager、secretary、managedby
Oracle Access Managerに取り入れられた補助クラスの場合、次を使用します。
obgroupadministrator、obgroupcreator
「パススルー・モード」の場合、次を選択します。
常時
接続情報: 想定される作業量に基づいて次の接続情報をOracle Virtual Directoryに設定します。
Oracle Access Managerの一般設定のカスタマイズの手順
前述の情報を確認します。
Virtual Directory Managerのサーバー・ナビゲータ・ウィンドウで、サーバーを選択し、アダプタ名を検索して選択します。
右側のペインで「ルーティング」タブをクリックします。
「一般設定」で、可視性が内部に設定されていることを確認します。
次に例を示します。
一般設定
可視性: 内部（分割プロファイルのアダプタ用）
この項で説明する設定がアダプタに使用されていることを確認します。
「終了」をクリックします。
サーバー・ナビゲータ・ウィンドウでアダプタ名を右クリックし、「サーバーに保存」を選択します。
結合ビュー・アダプタによって使用されるアダプタを設定する場合、プライマリおよびセカンダリ・アダプタの可視性は内部に設定し、これらが結合ビュー・アダプタによってのみ起動されるようにする必要があります。
アダプタの動作中は、パフォーマンスを観察するとともにログを診断し、アダプタによって特定の操作が必要以上に繰り返し起動されていないことを確認します。このような兆候がある場合は、次の機能を使用して、このアダプタによる不要な操作をフィルタでブロックします。全体的なパフォーマンスを向上させるために、この手順は非常に重要です。
包含用のフィルタ
除外用のフィルタ
DN照合
ルーティング設定のカスタマイズの手順
サーバー・ナビゲータ・ウィンドウでアダプタ名を選択します。
右側のペインで「ルーティング」タブをクリックします。
環境に応じてオプションを選択します。
包含用のフィルタ
除外用のフィルタ
DN照合
通常どおりサーバーに保存します。
「Oracle Access ManagerとOracle Virtual Directoryの実装のテンプレート」で説明されているように、オラクル社提供のサンプル・アダプタ・テンプレートには、複数のプラグインがすでに含まれています。プラグインには次の2つのタイプがあります。
プラグイン: 構成用としてパラメータ・ベースのユーザー・インタフェースを提供する事前定義のプラグイン。
マッピング・プラグイン: マッピング・スクリプト用のプラグイン。
作業上、次の点に注意してください。
オラクル社提供のサンプル・テンプレートを使用する場合、プラグインを変更するのみです。
オラクル社提供のサンプル・テンプレートを使用しない場合、アダプタにプラグインを追加する必要があります。次に例を示します。
前述の説明のとおり、Active DirectoryおよびADAMアダプタには、オラクル社提供のサンプル・テンプレートに含まれる2つの特定のプラグインが必要です。
オラクル社提供のサンプル・テンプレートを使用しない場合、Active Directoryのパスワード・プラグインとして作成するSSLアダプタを作成対象のオープン接続アダプタに追加するとともに、Active Directoryの範囲属性プラグインも追加する必要があります。この場合、SSLアダプタと同じようにマップされたネームスペースを指定するようにしてください。「LDAPディレクトリのアダプタの作成」を参照してください。
次の手順は例としてのみ示します。Virtual Directory Managerの使用の詳細は、Oracle Virtual Directoryのドキュメントを参照してください。
マッピング・ファイルを参照するためのアダプタ・プラグインの編集の手順
次の作業を実行します。
Virtual Directory Managerのサーバー・ナビゲータ・ウィンドウで、プロジェクトとサーバーを選択し、プラグインを追加または検証するアダプタ名を検索して選択します。
右側のペインで「プラグイン」タブをクリックします。
「アダプタ・プラグイン」画面で、次の作業を行います。
ADAMまたはActive Directoryの場合、次のプラグインが次の順序で必要です。
Active Directoryの範囲属性OblixADMapping（前に作成したマッピング・ファイル）
Active Directoryのパスワード
上下矢印を使用して環境に応じてプラグインを配置します。
前に作成したマッピング・ファイルが表示されていない場合は、次のようにします。
Active DirectoryまたはADAMアダプタ用としてOracle以外のテンプレートを使用する場合、パスワードを処理するために前に作成したSSLアダプタを追加します。
通常どおり終了し、保存およびデプロイします。
これで、前述した他のすべての重要な作業が完了したため、アイデンティティ・システムのインストールおよび設定を実行できます。
アイデンティティ・システムのインストールおよび設定の実行の手順
前述のタスクをすべて完了します。
WebPass: 第5章「WebPassのインストール」で説明されているように、WebPassをインストールします。
アイデンティティ・システムの設定: 次の仕様を使用してアイデンティティ・システムを設定してから、通常どおりに設定を終了します。
User Data Directory Server: ディレクトリ・タイプとしてData Anywhereを選択します。
User Data ... Host: Oracle Virtual Directoryをホストしているコンピュータを指定します。
User Data ... Port: Oracle Virtual DirectoryのLDAPライセンス・ポートを指定します。
Searchbase: 仮想ツリーの任意の場所にあるOracle Virtual Directoryの仮想DNを指定します。たとえば、o=ovd_data,o=usと指定します。
Configuration Data Directory Server: アイデンティティ・サーバーのインストール時に指定したネイティブ・ディレクトリを選択します。構成（およびポリシー・データ）は、Oracle Virtual Directory仮想ディレクトリの外部に格納する必要があります。
Automatically Update Schema: 「Yes」を選択し、Oracle Access Managerの補助属性を使用してOracle Virtual Directoryスキーマを自動的に更新します。
Specify Person and Group Object Classes: 「Yes」を選択し、Oracle Access Managerの補助属性を使用してOracle Virtual Directoryスキーマを自動的に更新します。
User Object Class: inetOrgPersonを指定します。
Group Object Class: groupOfUniqueNamesを指定します。
Automatically Configure Person and Group Object Classes: 「Yes」または「No」を選択し、通常どおりOracle Virtual Directoryスキーマを構成します。
ポリシー・マネージャ: 「ポリシー・マネージャのインストール」の章で説明されているように、後述の特定の詳細を使用してポリシー・マネージャをインストールおよび設定してから、通常どおりに設定を完了します。
前述の説明に従って、設定時にユーザー・データ・ディレクトリ・サーバーの詳細を指定します。
ポリシー・マネージャの設定時に次を指定します。
アクセス・サーバー: 第8章「アクセス・サーバーのインストール」で説明されているように、アクセス・サーバーをインストールします。この場合、次のようにします。
構成データ・ディレクトリ・サーバーに関する情報を指定します。
Oracle Access Managerのポリシー・データの格納場所を指定します。
求められた場合、次の情報を指定します。
WebGate: 第9章「WebGateのインストール」で説明されているように、WebGateをインストールします。
フェイルオーバー: 次の説明に従って構成します。
実装をテストする場合、ネイティブ・ディレクトリからのユーザー・データの取得が必要なOracle Access Managerの機能を実行してください。
この操作が実行されると、実装は成功です。
次の項では、Oracle Access Manager向けのOracle Virtual Directoryの実装の様々な側面に関する技術上の詳細を説明します。
Oracle Access Managerの特定の機能では、最上位の仮想ディレクトリのスキーマと各ターゲット・データ・ストアのスキーマ（またはデータベースの対応フィールド）の両方に特定の属性が存在する必要があります。
仮想ディレクトリ・スキーマは、次のように自動的に拡張できます。
アイデンティティ・システムをインストールおよび設定するときに、Data Anywhereをユーザー・データ・ディレクトリ・サーバーとして選択する場合、Oracle Virtual Directoryスキーマを自動（または手動）で拡張できます。アイデンティティ・システムのインストールおよび設定の詳細は、第II部「アイデンティティ・システムのインストールおよび設定」を参照してください。
以前のインストールをOracle Access Manager 10g（10.1.4.3）にアップグレードした後、「ディレクトリ・スキーマの拡張」で説明されているように、ldapmodifyユーティリティを使用してOracle Virtual Directoryスキーマを手動で拡張する必要があります。
「ディレクトリ・スキーマの拡張」で説明されているように、適切なldifファイルを使用してldapmodify.exeユーティリティを実行し、ターゲットLDAPディレクトリ・スキーマを拡張します。
プライマリ・データベース表内のすべてのユーザー・アカウントを適切なクラスにマップし、仮想ディレクトリのオブジェクト・クラスをシミュレートします。「ターゲット・データベース表への属性の追加の概要」を参照してください。
プライマリ・データベース表に追加列を作成し、Oracle Access Managerの特別な機能を有効化する補助ユーザー属性をシミュレートします。「ターゲット・データベース表への属性の追加の概要」を参照してください。
アンバウンド・データまたはユーザー・データに対しては長さが1000のNVARCHAR、Oracle Access Manager固有のすべての属性に対しては長さが240のVARCHARを使用します。
表10-7は、特定のUser Manager機能に必要なOracle Access Managerの補助属性を示しています。
|
注意: Oracle Virtual Directoryを使用する場合、ロケーション・オブジェクトはサポートされないため、User Managerアプリケーションではユーザー・ロケーション機能はサポートされません。 |
表10-7 User Manager機能に必要な拡張属性
| User Manager機能 | 必須属性 | 推奨される属性のタイプおよび長さ |
|---|---|---|
|
ユーザーの追加/アクティブ化/非アクティブ化 |
Obuseraccountcontrol |
VARCHAR (240) |
|
ワークフローのサロゲート |
oboutofofficeindicator |
VARCHAR (240) |
|
リセット時のパスワード変更 |
obpasswordchangeflag |
VARCHAR (240) |
|
パスワードの最大ログイン試行回数 |
oblogintrycount |
VARCHAR (240) |
|
パスワード有効期間 |
obpasswordcreationdate |
VARCHAR (240) |
|
パスワード期限切れ通知期間 |
obpasswordcreationdate |
VARCHAR (240) |
|
パスワードのロックアウト継続時間 |
oblockouttime |
VARCHAR (240) |
|
パスワードのログイン試行のリセット |
oblastloginattemptdate |
VARCHAR (240) |
|
パスワードの最小期間 |
obpasswordcreationdate |
VARCHAR (240) |
|
パスワード履歴 |
obpasswordhistory オプションのパスワード履歴のサポート |
NVARCHAR (1000) |
|
チャレンジ・レスポンス |
チャレンジ・フレーズおよびチャレンジ・レスポンスの顧客属性 |
NVARCHAR (1000) |
|
チャレンジ・レスポンスのログイン試行のリセット |
oblastresponseattemptdate |
VARCHAR (240) |
|
チャレンジ・レスポンスのロックアウト継続時間 |
Obresponsetimeout oblockouttime |
VARCHAR (240) VARCHAR (240) |
|
チャレンジ・レスポンスの最大ログイン試行回数 |
obresponsetries |
VARCHAR (240) |
表10-8は、特定のGroup Manager機能に必要なOracle Access Managerの補助属性を示しています。
表10-8 Group Manager機能に必要な拡張属性
| Group Manager機能 | 必須属性 | 推奨される属性のタイプおよび長さ |
|---|---|---|
|
サブスクリプション・タイプ |
obgroupsubscriptiontype |
VARCHAR (240) |
|
グループ拡張 |
obgroupexpandeddynamic |
VARCHAR (240) |
|
純動的グループ |
obgrouppuredynamic |
VARCHAR (240) |
|
グループ管理者 |
obgroupadministrator 仮想ディレクトリは、グループごとに1名のみの管理者をサポートする必要がある。 |
NPVARCHAR (1000) |
|
サブスクリプション・メッセージ |
obgroupsubscribemessage |
NPVARCHAR (1000) |
|
登録解除メッセージ |
obgroupunsubscribemessage |
NPVARCHAR (1000) |
|
サブスクリプション・フィルタ |
obgroupsubscriptionfilter |
NPVARCHAR (1000) |
|
サブスクリプション通知タイプ |
仮想ディレクトリは、グループごとに1つのみのサブスクリプションをサポートする必要がある。 |
NPVARCHAR (1000) |
|
動的フィルタ |
obgroupsubscribenotification サブスクリプション通知と登録解除通知のどちらかを実装できるが、両方の機能を同時には実装できない。 |
NPVARCHAR (1000) |
|
単純アクセス制御 |
obgroupdynamicfilter 仮想ディレクトリは、グループごとに1つのみの動的フィルタをサポートする必要がある。 |
|
|
グループ・タイプ |
obgrouptype 仮想ディレクトリは、グループごとに1つのみのグループ・タイプをサポートする必要がある。 |
|
|
選択可能サブスクリプション・タイプ |
obsubscriptiontypes 仮想ディレクトリは、グループごとに1つのみのサブスクリプション・タイプをサポートする必要がある。使用可能なサブスクリプション・タイプは、「オープン」、「閉じる」、「フィルタでオープン」および「ワークフロー経由で制御」。 |
NPVARCHAR (1000) |
DN変換ツールキットは、既存のOracle Access Managerインストールを使用しているときにOracle Virtual Directoryを統合する場合に使用します。DN変換ツールキットは、構成/ポリシー・ツリーにあるユーザー・データ関連のすべてのネイティブDN接尾辞を論理DN接尾辞に変換します。
DN変換ツールキットは、DataAnyWhereのアイデンティティ・サーバー・インストールの一部として自動的にインストールされます。表10-9は、このツールキットの内容を示しています。
表10-9 Oracle Access ManagerのDN変換ツールキットの内容
| \identity\oblixからのディレクトリ・パス | ファイル・コンポーネント | 説明 |
|---|---|---|
|
\apps\common\bin\ |
globalparams.xml |
特に、検索ベースの検索範囲を制御するファイル。 |
|
\lib |
obxmlengine.dll（Windows） obxerces-c21.dll（Windows） msvci70.dll（Windows） msvci70d.dll（Windows） msvcr70.dll（Windows） msvcr70d.dll（Windows） libxmlengine.so（Solaris） libstdc++.so.5（Solaris） libgcc_s.so.1（Solaris） Solarisに必要なすべてのldap sdkライブラリ |
WindowsおよびSolaris用のライブラリ。 |
|
\tools\DataAnyWhere |
README |
内容の概要、ランタイム要件、およびDN変換ツールキットのコンポーネントの簡単な使用例。 |
|
\tools\DataAnyWhere \conversion_tools |
obmigrateDN.exe 注意: obmigrateDNを使用して作成されたLDIFは、次のパスに格納されます。 C:\Program Files\NetPoint\identity \oblix\tools\migration_tools \obmigratedata obmigrateDNmsg.lst |
DN変換バイナリおよび構成ファイル。 Oracle Virtual Directoryを既存のアイデンティティ・サーバー・インストールと統合する場合、obmigrateDNは、Oracle Access Managerの構成ツリー内のユーザーおよびグループDNを変換する。この場合、obmigrateDNは、Oracle Virtual DirectoryのDN固有の操作を処理するためにobmigratedataを内部的にコールする。これにより、obmigratedataは、ldapmodify実行可能ファイルを参照する。 |
|
\tools\DataAnywhere \features\ \OracleAccessManagerOViDFeatures |
feature.xml |
|
|
\tools\DataAnyWhere \OblixUserSchema |
ADUserSchema.ldif ADAuxSchema.ldif ADAM_user_schema_add.ldif ADAMAuxSchema.ldif f iPlanet_user_schema_add.ldif iPlanet_user_schema_delete.ldif NDS_user_schema_add.ldif NDS_user_schema_delete.ldif v3.user.ibm_at.ldif v3.user.ibm_oc.ldif schema.oblix.xml VDE_user_schema_add.ldif VDE_user_schema_delete.ldif 注意: 可能であれば、アイデンティティ・サーバー・インストールに用意されているldifファイルを使用してください。 |
schema.oblix.xmlは、Oracle Access Managerのユーザー・スキーマを仮想ディレクトリまで拡張する。 VDE_user_schema_add.ldifは、Oracle Access Managerの属性を使用してOracle Virtual Directoryスキーマを拡張する。 その他のファイルは、Oracle Access Managerのユーザー・スキーマを、Oracle Access ManagerとOracle Virtual Directoryの実装によってサポートされているディレクトリ・サーバーまで拡張する。 |
|
\tools\DataAnywhere \plugins \OracleAccessmanagerOViDTemplates |
plugin.xml |
|
|
\tools\DataAnywhere \plugins \OracleAccessmanagerOViDTemplates \adapter_templates |
OblixADAdapterUsingMapper_adapter_ template.xml OblixADAdapterUsingScript_adapter_ template.xml OblixADSSLAdapterUsingMapper_adapter_ template.xml OblixADAMAdapterUsingMapper_adapter_ template.xml OblixADAMAdapterUsingScript_adapter_ template.xml OblixADAMSSLAdapterUsingMapper_a dapter_template.xml OblixSunOneAdapterUsingMapper_adapter_ template.xml OblixSunOneAdapterUsingScript_adapter_ template.xml 詳細は、次を参照。 |
テンプレートを必要とするディレクトリ・サーバー用のOracle Virtual Directoryのアダプタ・テンプレート。 これらは、アダプタの作成のベースとして使用できる。 各テンプレートには、基本設定、事前構成データ、プラグインおよびプラグイン・パラメータが含まれる。 |
|
\tools\DataAnywhere \plugins \OracleAccessmanagerOViDTemplates \mapping_templates |
OblixADAMMapping_mpy.xml OblixADMapping_mpy.xml OblixDBMapping_mpy.xml OblixeDirectoryMapping_mpy.xml OblixSunOneMapping_mpy.xml |
マッピング・スクリプト・テンプレート。 これらのサンプル・マッピングにより、アダプタ・テンプレートのオブジェクト・クラス・マッパー・プラグインによって生成された構成と同じ構成が実行される。 マッピング・スクリプトの方が柔軟性があるため、プラグインでは不可能な高度な調整を行うことができる。 |
|
\tools \ldap_tools |
ldapmodify.exe libobnspr4.dll libobplc4.dll libobplds4.dll obnsldap32v50.dll obnsldappr32v50.dll obnsldapssl32v50.dll obnss3.dll obsoftokn3.dll obsoftokn3.dll |
DN変換ツールキットとともに使用するldapmodifyツール。 Windows用のライブラリ・ファイル。 |
|
\tools \migration_tools \obmigratedata |
at_DN_Conversion_map_osd_offline.lst oc_DN_Conversion_map_osd_offline.lst at_DN_Conversion_map_osd_online.lst oc_DN_Conversion_map_osd_online.lst obmigratedata.exe obmigratedatamsg.lst |
実行時にobmigratedataが必要とするファイル。 これらには、特別な処理を必要とするオブジェクト・クラスと属性の詳細が含まれる。 これは通常のアップグレードと同じだが、DN変換ツールの場合、オフラインおよびオンライン・モードで特別な処理を必要とする点が異なる（READMEファイルを参照）。 |
DN変換ツールは、Oracle Access Managerの構成およびポリシー・ツリーの構成およびポリシー・ブランチのネイティブDNを、仮想ディレクトリが使用可能な論理（仮想）DNに変更します。次のツールを使用します。
IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\conversion_tools\
obmigrateDN.exe
変換を正常に実行するには、Oracle Access Managerディレクトリが次の2つの条件を満たしている必要があります。
Oracle Access Managerの構成およびポリシー・データがOracle Virtual Directoryの外部のネイティブ・ディレクトリに存在すること。
Oracle Access Managerからは、この製品から参照できるすべてのユーザー・データが含まれる、Oracle Virtual Directory仮想ディレクトリとは別のディレクトリに、この構成およびポリシー・データが属しているように見えること。
変換するDN属性のリストが含まれるファイル
ネイティブDNを論理DNに関連付ける作成対象のマッピング・リスト
ホスト名、ポート番号、バインドDN、パスワード、ディレクトリ・タイプ、構成DN、Oblixノード、インストール・ディレクトリ、ネイティブDN、論理DN、モード（オンライン、オフライン、テスト）
このツールが変換を行うのは、Oracle Virtual Directoryでドメインが異なる場合のみです。次に例を示します。
Oracle Access ManagerのDNが次のとおりだとします。
o=company, c=us
また、Oracle Virtual Directory上のiPlanetのDNが次のとおりだとします。
o=iPlanet, o=company,c=us
このとき、入力時に指定されたマッピング詳細を参照して変換が実行されます。
属性自体のみが異なる場合、マッピングは実行されません。次に例を示します。
cn=manisha, o=company, c= us
この場合、Oracle Virtual Directoryにはマップできません。
cn=manisha, o=iPlanet, o=company, c=us
このツールは、DN値ごとに少なくとも1回は実行する必要があります。
|
注意: 構成ブランチがポリシー・ブランチと同じディレクトリ・サーバー上にない場合、DN値ごとにこのツールを2回実行する必要があります。 |
このツールはSSLをサポートしていません。
スキーマのDSMLバージョンは自動的にはロードされません。
既存のOracle Access Managerインストールをアップグレードする場合、システム設定を再実行する前に、統合するディレクトリからDBProfileブランチを手動で削除する必要があります。
|
注意: システム設定の前に必ず古いDBProfileを手動で削除してください。設定後は、新しいDBProfileが自動的に作成されます。 |
このツールは、ADSI（Active Directory Services Interface）をサポートしていません。セキュアな接続が必要な場合は、かわりにSSLを使用する必要があります。
オラクル社では、各ディレクトリおよびデータベースを容易に設定できるようにアダプタ・テンプレートおよびスクリプト・テンプレートを提供しています。アダプタを構成する場合、後で説明するテンプレートを選択し、スキーマ・マッピングおよび特別な処理を実行できます。マッピング基準によっては、これらのテンプレートをそのまま使用することも、調整のベースとして使用することもできます。
用意されているテンプレートは、「表10-9 Oracle Access ManagerのDN変換ツールキットの内容」に一覧表示されています。各テンプレートの実行機能を完全に理解するには、次の説明を参照してください。
|
注意: オブジェクト・クラス・マッパー・テンプレートは、パラメータ・ベースのユーザー・インタフェースを持つプラグインです。オブジェクト・クラス・マッパー・テンプレートおよびスクリプト・テンプレートでは、同じ操作が実行され、同じ結果が生成されます。場合によってはスクリプトを使用する方が自由度が高くなりますが、マッパーを使用する方が便利な場合もあります。どちらを使用するかは自由に選択できます。 |
詳細は、「データ・ストア・アダプタの作成」および「DN変換ツールキットの概要」を参照してください。
Oracle Access Managerには、Active Directory用として次の3つのテンプレートが用意されています。
このテンプレートは、次が含まれるオブジェクト・マッパー・プラグインを使用して、Active DirectoryのuserおよびgroupデータをOracle Virtual Directoryのinetorgpersonおよびgroupofuniquenamesに変換するアダプタを定義します。
inetorgperson、groupofuniquenamesおよびOracle Access Managerのユーザー補助クラスのDN構文を持つすべての属性を使用してDN属性を設定し、これらのDNをネイティブDN形式で格納するためのメカニズム。
Active Directoryの範囲属性用のプラグイン。
Active Directoryは、xxxバイトのチャンクとしてエントリを返します。このプラグインは、すべてのチャンクを1つの結果エントリとして連結します。
表10-10に示すオブジェクト・クラスおよび属性をマップするためのパラメータ・ベースのユーザー・インタフェースを備えるオブジェクト・クラス・マッパー用のプラグインも含まれます。
表10-10 OblixADAdapterUsingMapper、オブジェクト・クラス・マッパーのプラグイン・パラメータ
| パラメータ | 値 | コメント |
|---|---|---|
|
|
true |
Active Directoryが静的補助クラスとして構成されていることが前提。 |
|
addAttribute-group |
samaccountname=%cn% |
オブジェクト・クラスがgroupである場合、samaccountname属性を追加し、値をcnと同じ値に設定。これは、Active Directoryでは、groupに対してsamaccountnameが必要であるため。 |
|
addAttribute-group |
|
オブジェクト・クラスがgroupである場合、 |
|
|
uniqueMember= member |
Oracle Virtual Directoryの |
|
|
owner= |
Oracle Virtual Directoryのowner属性をActive DirectoryのmanagedBy属性にマップする。 |
|
|
uid=samaccountname |
Oracle Virtual Directoryのuid属性をActive Directoryの |
|
|
次も参照。
|
オブジェクト・クラスがgroupである場合、これらの属性をフィルタ処理によって除外する。これは、Active Directoryのgroupがこれらの3つの属性をサポートしていないため。 |
|
|
groupofuniquenames=group |
Oracle Virtual Directoryの |
|
|
inetorgperson=user |
Oracle Virtual Directoryのinetorgpersonオブジェクト・クラスをActive Directoryのuserオブジェクト・クラスにマップする。 |
|
|
（システム属性のリスト） |
リスト内のすべての属性をフィルタ処理によって除外する。Active Directoryには、Oracle Access Managerからは参照できないようにする必要があるシステム属性の長いリストがある。 |
|
|
ActiveDirectory |
ディレクトリ・タイプ。 |
|
|
obuseraccountcontrol |
Active Directoryアダプタがアクティブ化および非アクティブ化の対象を検索するために使用するOracle Access Managerの属性名。Active Directoryアダプタは、これに基づいてネイティブ・フラグuseraccountcontrolを設定する。 |
|
|
ACTIVATED |
obuseraccountcontrolのアクティブ化の値。 |
|
|
DEACTIVATED ObWfPendingActivate ObWfPendingDeactivate |
obuseraccountcontrolの非アクティブ化の値。 |
|
|
person organizationalPerson OblixOrgPerson oblixpersonpwdpolicy oblixadvancedgroup oblixgroup oblixAuxLocation |
フィルタ処理によって除外する補助クラス。これは、Active Directoryが静的補助クラスとして構成されているという前提に基づく。 |
表53のパラメータを使用してユーザーのパスワードを設定または変更するためにSSL接続を使用する必要があるActive Directoryのパスワード用のプラグインが含まれます。
|
注意: 現在のアダプタにオープン接続が使用されている場合、このプラグインは、SSL接続を使用して構成されているアダプタにパスワードの設定/変更をリダイレクトします。 |
このテンプレート（OblixADAdapterUsingScript）により、前述の説明とまったく同じ結果が得られます。このテンプレートの項目の内容は、「Active Directory用のOblixADAdapterUsingMapper」の1、2および4の内容と同じです。
OblixADAdapterUsingScriptを使用する場合の唯一の違いは項目3です。この場合、この項目は次のようになります。
3. 「表10-10 OblixADAdapterUsingMapper、オブジェクト・クラス・マッパーのプラグイン・パラメータ」のパラメータがあり、マッピング・スクリプト・テンプレートOblixADMappingに定義されているPythonで作成されたプラグイン・スクリプトが、「Active Directory用のOblixADAdapterUsingMapper」の項目3でオブジェクト・クラス・マッパーについて記載されているすべての機能を実行します。
このテンプレートは、SSLを介してActive Directoryに接続するアダプタを定義します。これは、前述の項目4で説明したリダイレクト先のアダプタ用です。次を参照してください。
ADAM用として次の3つのテンプレートが用意されています。
このテンプレート（OblixADAMAdapterUsingMapper）は、次が採用されたオブジェクト・マッパー・プラグインを使用して、ADAMのuserおよびgroupデータをOracle Virtual Directoryのinetorgpersonおよびgroupofuniquenamesに変換するアダプタを定義します。
inetorgperson、groupofuniquenamesおよびOracle Access Managerのユーザー補助クラスのDN構文を持つすべての属性を使用してDN属性を設定し、これらのDNをネイティブDN形式で格納するためのメカニズム。
Active Directoryの範囲属性用のプラグイン。
ADAMは、xxxバイトのチャンクとしてもエントリを返します。このプラグインは、すべてのチャンクを1つの結果エントリとして連結します。
表10-12に示すオブジェクト・クラスおよび属性をマップするためのパラメータ・ベースのユーザー・インタフェースを備えるオブジェクト・クラス・マッパー用のプラグインも含まれます。
表10-12 OblixADAMAdapterUsingMapper、オブジェクト・クラス・マッパーのパラメータおよび値
| パラメータ | 値 | コメント |
|---|---|---|
|
|
（設定なし。デフォルトはfalse） |
動的補助クラスが前提。ADAMが静的補助クラスとして構成されている場合、trueに設定。 |
|
|
|
オブジェクト・クラスがgroupである場合、groupType属性を追加し、デフォルト値を4に設定。この値は、顧客のニーズに応じて変更できる。 |
|
|
|
Oracle Virtual DirectoryのuniqueMember属性をADAMのmember属性にマップする。 |
|
|
|
Oracle Virtual Directoryのowner属性をADAMの |
|
|
uid=samaccountname |
Oracle Virtual Directoryのuid属性をADAMの |
|
|
seeAlso,businessCategory,o |
オブジェクト・クラスがgroupである場合、これらの属性をフィルタ処理によって除外する。これは、Active Directoryのgroupがこれらの3つの属性をサポートしていないため。 |
|
|
groupofuniquenames=group |
Oracle Virtual DirectoryのgroupOfUniqueNamesオブジェクト・クラスをActive Directoryのgroupオブジェクト・クラスにマップする。 |
|
|
inetorgperson=user |
Oracle Virtual Directoryのinetorgpersonオブジェクト・クラスをADAMのuserオブジェクト・クラスにマップする。 |
|
|
（システム属性のリスト） |
リスト内のすべての属性をフィルタ処理によって除外する。ADAMには、Oracle Access Managerからは参照できないようにする必要があるシステム属性の長いリストがある。 |
|
|
ADAM |
ディレクトリ・タイプ。 |
|
|
obuseraccountcontrol |
ADAMアダプタがアクティブ化および非アクティブ化の対象を検索するために使用するOracle Access Managerの属性名。ADAMアダプタは、これに基づいてネイティブ・フラグuseraccountcontrolを設定。 |
|
|
ACTIVATED |
obuseraccountcontrolのアクティブ化の値。 |
|
|
DEACTIVATED ObWfPendingActivate ObWfPendingDeactivate |
|
|
filterAuxiliaryClass |
（設定なし） |
フィルタ処理によって除外する補助クラス。これは、ADAMが動的補助クラスとして構成されているという前提に基づく。ADAMが静的補助クラスとして構成されている場合、このパラメータに補助クラス名を指定する。 |
Active Directoryのパスワード用のプラグインが含まれます（ADAMでは、表55のパラメータを使用してユーザーのパスワードを設定または変更するためにSSL接続を使用する必要があります）。
|
注意: 現在のアダプタにオープン接続が使用されている場合、このプラグインは、SSL接続を使用して構成されているアダプタにパスワードの設定/変更をリダイレクトします。 |
このテンプレート（OblixADAMAdapterUsingScript）により、前述の説明とまったく同じ結果が得られます。このテンプレートの項目の内容は、「ADAM用のOblixADAMAdapterUsingMapper」の1、2および4の内容と同じです。
OblixADAMAdapterUsingScriptを使用する場合の唯一の違いは項目3です。この場合、この項目は次のようになります。
3. 「表10-12 OblixADAMAdapterUsingMapper、オブジェクト・クラス・マッパーのパラメータおよび値」のパラメータがあり、テンプレートOblixADAMMappingに定義されているPythonで作成されたプラグイン・スクリプトが、「ADAM用のOblixADAMSSLAdapterUsingMapper」の項目3でオブジェクト・クラス・マッパーについて記載されているすべての機能を実行します。
このテンプレートは、SSLを介してADAMディレクトリに接続するアダプタを定義します。これは、前述の項目4で説明したリダイレクト先のアダプタ用です。次を参照してください。
Sun Directory Server用としては、次の2つのテンプレートが用意されています。
このテンプレートは、次が含まれるオブジェクト・マッパー・プラグインを使用して、Sun Directory Server（旧SunOne）のinetorgpersonおよびgroupofuniquenamesをOracle Virtual Directoryのinetorgpersonおよびgroupofuniquenamesに変換するアダプタを定義します。
inetorgperson、groupofuniquenamesおよびOracle Access Managerのユーザー補助クラスのDN構文を持つすべての属性を使用してDN属性を設定するためのメカニズム。これにより、これらのDNをネイティブDN形式で格納します。
表10-14に示すオブジェクト・クラスおよび属性をマップするためのパラメータ・ベースのユーザー・インタフェースを備えるプラグイン（オブジェクト・クラス・マッパー）も含まれます。
表10-14 OblixSunOneAdapterUsingMapper、オブジェクト・クラス・マッパーのパラメータ
| パラメータ | 値 | コメント |
|---|---|---|
|
|
SunOne |
ディレクトリ・タイプ。 |
|
|
obuseraccountcontrol |
SunOneアダプタがアクティブ化および非アクティブ化の対象を検索するために使用するOracle Access Managerの属性名。SunOneアダプタは、これに基づいてネイティブ・フラグnsaccountlockを設定。 |
|
|
ACTIVATED |
obuseraccountcontrolのアクティブ化の値。 |
|
|
DEACTIVATED ObWfPendingActivate ObWfPendingDeactivate |
obuseraccountcontrolの非アクティブ化の値。 |
このテンプレート（OblixSunOneAdapterUsingScript）により、前述の説明とまったく同じ結果が得られます。このテンプレートの項目の内容は、「SunOne用のOblixSunOneAdapterUsingMapper」の1の内容と同じです。
OblixSunOneAdapterUsingScriptを使用する場合の唯一の違いは項目2です。この場合、この項目は次のようになります。
2. 「表10-14 OblixSunOneAdapterUsingMapper、オブジェクト・クラス・マッパーのパラメータ」のパラメータがあり、テンプレートOblixSunOneMappingに定義されている、Pythonで作成されたプラグイン・スクリプト。この表により、「SunOne用のOblixSunOneAdapterUsingMapper」の項目2でオブジェクト・クラス・マッパーについて記載されているすべての機能を実行できます。
eDirectory用として次の2つのテンプレートが用意されています。
このテンプレートは、次が含まれるオブジェクト・マッパー・プラグインを使用して、eDirectoryのinetorgpersonおよびgroupofuniquenamesをOracle Virtual Directoryのinetorgpersonおよびgroupofuniquenamesに変換するアダプタを定義します。
inetorgperson、groupofuniquenamesおよびOracle Access Managerのユーザー補助クラスのDN構文を持つすべての属性を使用してDN属性を設定するためのメカニズム。これにより、これらのDNをネイティブDN形式で格納します。
表10-15に示すオブジェクト・クラスと属性をマップするためのパラメータ・ベースのユーザー・インタフェースを備えるプラグイン（オブジェクト・クラス・マッパー）。
表10-15 eDirectory用のOblixeDirectoryAdapterUsingMapper
| パラメータ | 値 | コメント |
|---|---|---|
|
|
SunOne |
ディレクトリ・タイプ。 |
|
|
obuseraccountcontrol |
eDirectoryアダプタがアクティブ化および非アクティブ化の対象を検索するために使用するOracle Access Managerの属性名。これにより、eDirectoryアダプタはネイティブ・フラグlogindisabledを設定。 |
|
|
ACTIVATED |
obuseraccountcontrolのアクティブ化の値。 |
|
|
DEACTIVATED、ObWfPendingActivate、ObWfPendingDeactivate |
obuseraccountcontrolの非アクティブ化の値。 |
このテンプレート（OblixeDirectoryAdapterUsingScript）により、OblixeDirectoryAdapterUsingMapperを使用して説明した内容とまったく同じ結果が得られます。
OblixeDirectoryAdapterUsingScriptを使用する場合の唯一の違いは項目2です。この場合、この項目は次のようになります。
2. 「eDirectory用のOblixeDirectoryAdapterUsingMapper」の項目2でオブジェクト・クラス・マッパーについて記載されているすべての機能を実行できる「eDirectory用のOblixeDirectoryAdapterUsingMapper」のパラメータがあり、OblixeDirectoryMappingテンプレートに定義されている、Pythonで作成されたスクリプト。
このテンプレートは、データベース用のアダプタを定義します。このテンプレートには、特定のマッピングは含まれていませんが、OblixDBMappingスクリプトはコールします。OblixDBMappingテンプレートに定義されているこのスクリプトは、Pythonで作成されており、LDAPの操作時にオブジェクト・クラスに関する不要な記載をフィルタ処理によって除外します。
次のマッピング・スクリプト・テンプレートは、前述のアダプタ・テンプレートによって使用されます。これらのサンプル・マッピングにより、アダプタ・テンプレートのオブジェクト・クラス・マッパー・プラグインによって生成された構成と同じ構成が実行されます。マッピング・スクリプトの方が柔軟性があるため、プラグインでは不可能な高度な調整を行うことができます。
これらのマッピング・スクリプト・テンプレートには、スキーマ・マッピングおよび特別な処理を実行するための代替スクリプトが用意されています。
OblixADMapping: このマッピング・テンプレートには、次の機能があります。
Active Directoryのuserおよびgroupデータをinetorgpersonおよびgroupofuniquenamesにそれぞれ変換します。
ユーザーがアクティブ化または非アクティブ化されるときにネイティブ・フラグを設定します。
静的補助オブジェクト・クラスを処理します。
grouptypeを4に設定します。
useraccountnameがcnと同じになるように設定します。
OblixADAMMapping: このマッピング・テンプレートには、次の機能があります。
Active Directoryのuserおよびgroupデータをinetorgpersonおよびgroupofuniquenamesにそれぞれ変換します。
ユーザーがアクティブ化または非アクティブ化されるときにネイティブ・フラグを設定します。
静的補助オブジェクト・クラスを処理します。
grouptypeを4に設定します。
OblixeDirectoryMapping: ユーザーがアクティブ化または非アクティブ化されるときにネイティブ・フラグを設定します。
OblixSunOneMapping: ユーザーがアクティブ化または非アクティブ化されるときにネイティブ・フラグを設定します。
次の項では、Oracle Virtual Directoryの実装に関するその他の情報について説明します。「データベースの接続性に関するヒント」も参照してください。
マッピングDN: マップされたDNは、Oracle Virtual Directoryの論理DNです。ただし、マップされたDNには物理ノードがありません。
アプリケーション（アイデンティティ・システムなど）が論理DNを検索し、DNの存在の有無を確認したりその属性を取得することが必要な場合、たとえば、ldp.exeユーティリティを使用して、エントリを手動で追加する必要があります。たとえば、マッピングDNがo=virtual companyである場合、次のように、ldp.exeを使用して対応するエントリを作成する必要があります。
obobjectclass: organization
o: virtual_company
ここで、organizationはxxx、virtual_companyはxxxです。
構成およびポリシー・データの参照DN: ポリシー・データで使用されるUIDなどの参照DNは、論理形式になっています。つまり、参照DNは、ネイティブ・ディレクトリではなくOracle Virtual DirectoryのDNとして格納されています。このため、Oracle Virtual Directoryのネームスペースのマッピングが完了した後、このマッピングは変更できません。ネームスペースのマッピングを変更すると、Oracle Access Managerの構成およびポリシー・データに格納されている参照DNに影響が及びます。
スキーマ・マッピング: 論理からネイティブに属性をマッピングする場合、属性の構文に注意するとともに、属性が多値と単一値のどちらであるかに注意してください。
Oracle Virtual Directoryからディレクトリにマップする場合、文字列構文の微調整を除いて、同じ構文のままにする必要があります。
Oracle Virtual Directoryからデータベースにマップする場合、「表10-16 Oracle Virtual Directoryからデータベースへのマッピング」を参考にしてください。
表10-16 Oracle Virtual Directoryからデータベースへのマッピング
| LDAP属性の構文 | MS SQLのデータ型 |
|---|---|
|
1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' |
binary |
|
1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' |
binary |
|
1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate'binary |
binary |
|
1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' |
binary |
|
1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' |
binary |
|
1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' |
tvarchar |
|
1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' |
timestamp |
|
1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' |
binary |
|
1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' |
numeric/int |
|
1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' |
binary |
|
1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' |
varchar |
|
1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' |
timestamp |
データベースの接続性に関する考慮点は、次のとおりです。
エントリ名の構成
複数表の書込み
多値属性
検索
書込み
連鎖削除
エントリ名の構成: エントリ名の一部（エントリ名の基本部分は除く）として使用されるデータベース・フィールドはすべて、データベース・アダプタを介してOracle Virtual Directoryにマップされて返される行に含まれる必要があります。
たとえば、ユーザー・オブジェクトの名前に共通名（cn）および組織単位（ou）の両方（cn=Joe User,ou=Marketing）が含まれる階層を作成する場合、cnおよびouは両方とも作成対象のエントリの一部である必要があります。
単純LDAPでは、ou属性は親エントリの一部であるため、この属性は必要ありません。データベースは階層的ではないため、この機能をサポートしながら、階層を定義するために大量の新しいメタデータを作成および管理しなくてすむようにするには、これが唯一の適切な方法です。
複数表の書込み: 1つのデータベース・アダプタに対して、複数の表を直接書き込むことはできません。これは、Oracle Virtual Directoryの設計上の制限ではなく、実際にはデータベース上の制限です。たとえば、データベースのビューが複数の表を示している場合、ほとんどのデータベースのビューは直接更新できません。
Oracle Virtual Directoryでは、独自の結合ビュー実装を使用してこの制限を回避しています。複数のデータベース・アダプタ（たいていは表ごとに1つ）を作成し、これらの関係を定義することにより、複数の表を介して構成されたエントリへの書込みをOracle Virtual Directoryが管理できるようになります。結合ビューの作成の詳細は、『Oracle Virtual Directory製品マニュアル』を参照してください。
多値属性: 通常、データベースでは、表の単一行内の1つのフィールドに複数の値は使用できません。配列型がサポートされている例外もありますが、これらのデータ型は比較的制限される傾向があります。ユーザーによっては、カンマやパイプ（|）などのデリミタを使用してフィールド内のデータ（アカウント・フラグなど）を区切ることにより、1行に複数の値を入力する場合があります。
従来のデータベース設計では、複数の値を持つフィールドは追加表に正規化するよう規定されています。データ・ウェアハウスの一部であるデータベースの場合、非正規化された表にすべてのフィールドのすべての順列を配置するという別の方式が使用されることがあります。
通常、Oracle Virtual Directoryはどちらのモデルもサポートしています。オラクル社は、非正規化された表に順列を配置する方式を最終的な手段としてのみ使用することをお薦めします。正規化されたセカンダリ表方式の場合、Oracle Access Managerでの検索に対して一貫性のある正確な結果が返されない可能性があります。
多値属性の詳細は、次を参照してください。
検索: 検索は、正規化された表または非正規化された表に対してサポートされています。この場合、必要に応じてデータベース・レベルの結合を構成する以外、他の作業は必要ありません。
検索に関して注意が必要な考慮点は、最も一般的な使用事例により、データベース・アダプタの現在の設計では、多値属性が検索されるとエントリの一部として検索と一致する値のみが返されるようになっている点です。これにより、大きなグループの検索時のパフォーマンスが向上します。Oracleでは、すべての値を返すための2次選択をサポートするために、将来のバージョンではこの構成を実現する予定です。それまでには、マッピングで追加検索を実行してすべての属性を取得できるようになります。
書込み: 正規化された表に対する書込みは、データベースの設計に基づいて属性を各表に分割する結合ビューを介して実行する必要があります。データベースの設計に関する一般的なガイドラインは複数存在し、すべての顧客のデータベースは異なるため、このような作業が必要です。
既存の重要な表を使用するほとんどの顧客は、これらの表の更新管理の一環としてストアド・プロシージャも使用します。これらのストアド・プロシージャはAPIコールと似ており、その構成およびコール方法はデータベースごとに独自の仕様になっていますが、コール自体は顧客独自の仕様になっています。Oracleでは、プラグイン・システムを使用してストアド・プロシージャをサポートしています。
Oracle Virtual Directoryは、エントリのRDNとして使用されるフィールドに関連付けられたエントリで使用される各フィールドの値を持つ非正規化された表に対する直接書込みを管理できます。追加、変更および削除はすべてサポートされます。
変更操作については、変更→置換操作によって既存の属性値が削除され、新しい属性値が追加される点に注意する必要があります。これは、SQLの挿入、更新および削除で構成された一連の操作ではなく、SQL削除とSQL挿入を意味します。ここで、正規化された表を持つ顧客には、挿入または削除によってデータベース内でその他のアクションがトリガーされるという潜在的な問題があります。このような場合、変更→置換操作を処理するプラグインを構成する必要があります。
ほとんどの顧客は、変更に対する直接的なSQLアクセスを使用していないか、複数の値を読取り専用として使用しているか、変更→追加および変更→削除のみを直接使用しているかのいずれかのため、このような状況にはなりません。たとえば、大きなグループに関する問題に取り組んでいる顧客の場合、Oracle Virtual Directoryを介してグループをデータベースに格納します。グループ・メンバーに関するほとんどの変更内容は、置換ではなく追加と削除です。
連鎖削除: 書込みに関する項で説明した問題の中で、Oracle Virtual Directoryによってデータベースへの直接書込みが処理される既存のデータベースについて最も注意が必要なのは、顧客データベースにおける連鎖削除の使用です。連鎖削除の場合、前の項で説明した変更→置換操作により、直接関係のある表の外部で削除がトリガーされる可能性があります。
ただし、このトリガーが正規化された表に基づいて行われる場合、単一値の正規化された表の変更時にはOracle Virtual Directoryにおいて削除→挿入操作ではなくSQL更新が実行されるため、これは問題ではありません。これにより、前述の問題は解消されます。
連鎖削除に関して潜在的に危険な設定が適用された特定の顧客状況に関して不明な点がある場合は、オラクル社にお問い合せください。また、Oracle Virtual Directoryのデバッグ・レベルを上げてテスト・データベースを指定することにより、LDAP操作の順序についてOracle Virtual Directoryによって生成されるSQLを確認することもできます。
詳細は、「Oracle Virtual Directoryの実装の問題」を参照してください。
